I just got home and gave the new build a trial. Seems to be working much better. I am not totally sure but there appear to be some artifacts that still make it outside the plot windows but only in the spaces between the control buttons. However this far from objectionable so I am content for now. I will let you know if there are any other interesting things that are unexpected should that happen.

Thanks again,
Rod

I just sent you my code, project file and some data files. Hopefully this will all work for you once it is compiled.

Rod

Unfortunately, if there is no data, the program immediately shuts down and the window closes. You will not be able to see the artifacts plotted outside the data plotting windows. I can rig up a small data folder to include along with the project folders.

Note this is self contained code, so there is no other source or libraries needed.

Rod

If the program would simply start without data, it should be sufficient.  You mentioned that the buttons don't appear at all when the program starts, correct?  We can tackle that issue at least initially.

Also, be sure not to include the executable and any object files.  Spam filters will stop email otherwise.

I don't have any real issue sending my code (other than dying of embarrassment from how horrible a coder I am).

Sending an entire project is problematic in that you will need data to plot in order for the program to do anything. I can try to bundle a small amount of data in with the project and zip it into a folder that you can extract and work from. Do you know how large of an email file your mail system can handle? If I can squeeze it into that size, then it should be possible.

I will have to wait until I get home tonight to send the email.

Note too there are other things going on in the program that I didn't discuss, like there is an option to create screen captures to make video from the output but that is an option that is access through the initialization file. I will try to include instructions on how to use/run the program when I send it.

Thanks again,
Rod

Would you be comfortable emailing your entire project to me at support@approximatrix.com?  It might be the quickest way to sort out the issue inside AppGraphics.  From your description, I really don't see any issues with your code.

Sorry, I didn't see your questions from earlier yesterday. My answers follow best as I can understand.

1) I have been using clearviewport from the beginning and it does what I think is should do. For example, when the the zoom-in button is pushed I set a flag in the callback subroutine that tells the main plotting loop that we want to change the plotting scale. In the plotting loop, there is a big if-then-else segment where all plotting control flags are checked. In the case of zoom-in, I reset the plotting scale and clear the viewport for plotting data at the new scale.

In this case clearviewport works fine, here is the segment of code for re-initializing the viewport for the new scaling:

! mcntrl=2 is Zoom In button actions
        pscale=4.0*pscale/5.0
       
        write(scalenumber,'(f8.2)')pscale
       
        call settextboxcontents(isclbox, scalenumber)
       
        mcntrl=0
         
        call setviewport(1,iwiny-iptx,iptx,iwiny,.true.)
         
        call setbkcolor(mBlack)
         
        call clearviewport()
         
        call setviewport(iptx+1,iwiny-iptx,iwinx,iwiny,.true.)
         
        call setbkcolor(mBlack)
         
        call clearviewport()

2) If understand your question, I don't do anything in the callback subroutines other that setting an action flag (mcntrl above) to tell the code what action to perform. I know this extremely simplistic coding but that is what I settled on to keep the callbacks simple. Here is the callback for the zoomin action:

    Subroutine zoominbut()
       
    integer::mcntrl
       
    common /control/ mcntrl
       
    mcntrl=2
   
    end subroutine zoominbut

3) Creating the buttons:

In the code, I start by creating all the items in the top control area of the program which includes all the text boxes, check box, other text and then I create all the buttons:

!Create all the bottons in the control viewport
   
ignore=createbutton(iwinx-ibutton-5,ibutwinsiz-2*ibtoffy-2,ibutton,ibtoffy,"Pause",pausebut)

All the button and other controls are created before the main data plotting loop ever starts and before I create the other plotting and informational viewports. I assume once created, they never need attention again and that was what worked before in the old versions I was using.

***************************************************************************************
I know you didn't ask for it but as an exercise, I thought I would include a high level flow.
From a program flow perspective the code starts:

Initialize all the variables to be used later
set up some color names for later use
Create the main execution window, setting up default text and colors
Create the Control view port which includes:
    Set the size
    Set default text and color
    Write the fixed text for the three left text boxes to follow
    Set up the three text boxes for the scale, File increment and file number and set their initial contents
    Set up the three text boxes for the x,y and z offsets and set their initial contents
    Create the check box for center-of-mass plotting
    Create the two two text boxes for the CM plotting dialog and initialize their contents.
    Write out the fixed text associated with those CM text boxes
    Create 12 buttons for all the button actions each with an associated callback subroutine
Create the informational text area of the program,set color (white) and default text properties
Create the two data plotting areas, set colors and then clear each new viewport.

At this point the main plotting loop begins
    Check for any control changes and perform actions needed for the associated control
    read in data from the current file number
    Check for CM positions to be calculated
    Begin object plotting loop
        Set up all the positioning constraints based on control sets
        Check to see if object is inside the plotting window
        Call setviewport for the X-Y plotting window
        Plot the object based on control conditions (includes plotting black for previous loop positions)
        Call setviewport for the Z-Y plotting window
        Plot the object based on control conditions (includes plotting black for previous loop positions)
        Save current positions to use for next iteration
        Check for last file or first file actions to reverse time plotting if needed; includes update the increment text             box in the control viewport
    End object plot loop
    Check for every fifth loop to output status to the control and text windows. This includes the following:
            Set and write text for updating the text boxes in the control window
            Set and write  text for updating the text in the information text area
End main loop
Exit

Sorry forgot to mention the OS in this post. I am using Win 7 Pro for most of my systems and for development. Um, I can try running the program on the on Win 10 system I have to see how it behaves. If it behaves different, I will let you know.

Rod

One additional question: What operating system are you using?  Drawing can vary between different versions of Windows, although one would think it wouldn't matter.

I've tried a few techniques, and I can't seem to replicate the issue you're reporting.  I have a few questions about how drawing is handled in your code.

First, I suspect with the older version you had been using that clearviewport was an especially useless function.  Were you using some sort of fill or call to bar to clear a viewport?  The current clearviewport is especially useful now in that it will actually fill a region with the background color as one might expect.  Additionally, are you using setviewport to restrict the drawing region?  That should work, and I would think it would cut down on artifacts occurring outside your drawing area (although that could be the bug you're describing).

Second, are you performing drawing inside a callback?  That shouldn't cause an issue (I can't cause one on my end), but it might. 

Third, when do you initialize the buttons?  And what drawing actions do you take after initializing the buttons?  I'm trying to hunt down why they wouldn't redraw.

AppGraphics jumps through some odd hoops to keep GUI program simple even though the background drawing is quite complicated on Windows.  Hunting down these bugs can be a bit problematic, especially if a user is writing AppGraphics code in a manner I'm not expecting (which isn't necessarily wrong, just different).

Not just yet.  I suspect I can find and fix the intial problem (disappearing buttons) rather easily.  The second problem, graphical artifacts, might be related to double-buffering and a failure to update all buffers appropriately.  I'll take a look at that as well.  The problems you've described should be caused entirely by AppGraphics itself as opposed to your code.

I don't intentionally plot data outside the windows that are set up for data plotting. That said, something I noticed this morning was that there are some data plotting artifacts outside the data plotting windows. I had never seen that before and my code explicitly prohibits plotting outside the confines of the data windows.

I tested that behavior this morning by restricting the plotting volume even further inside each window and could watch objects with the tighter constraints. Outside of the new constricted volume, no objects were plotted. But in the control interface area, I see what appear to be objects moving through the buttons; overwriting the button graphics. Weird.

Would it be helpful if I created a program flow?

Rod

That behavior is almost certainly due to how AppGraphics handles updating the window.  Basically, overlaying the Windows controls (buttons, etc.) over graphics can be problematic as Windows requests redraws.  It isn't your fault, though.  AppGraphics should be forcing the Windows control to the top regardless of redrawing. Let me see if I can replicate and fix the issue, and I'll let you know when a build is available.  If I do come across  quick fix in the meantime, I'll be sure to notify you.

I started a new thread from the one the other day since this is a different issue. In that previuos thread, Jeff suggested updating my SF package and so after some deliberation, I decided to try. I have had to work on other projects in the last day and they all behave properly but they are not AppGraphics code.

My AppGraphics application when recompiled I notice some different behaviors. It was easy to adjust the fonts as perhaps the defaults were changed. However, one thing I have been struggling with is that the function buttons I create to control the features of the plotting now appear and disappear in ways that I have not completely characterized.

Previously I have shared the screen shot of this application (https://flic.kr/p/rnZ1SS) and there are four areas within the created window that have activity. There are two large plotting areas where the data is plotted, there is the control are on top and then a text informational area in the middle.

What happens when the program starts is that all the control buttons (with the exception of the Pause and Reverse buttons) are invisible. Note that even though invisible, the area around the button is still active and will complete the desired action for that individual button. If i wait a few (several in some cases) seconds or if I move the entire window, all the buttons will appear and stay. They will stay only until one of the zoom-in or zoom-out buttons buttons is pushed; then they disappear for a while (indetermined). If I move the window all will return again.

Note too that some of the buttons show the "pushed" action and some do not but all function as to their actions when pushed.

I have tried a number of things in the last couple of days and have cleaned the code up some. However, in all honesty, I only vaguely understand what the actions of some of the AppGraphics commands do and I am not sure my program is structured in way that AppGraphics expects. Recall, I hacked this code together using your example code.

If any of this rings a bell with anyone, help would be appreciated. I can live with the current behavior but it is not ideal. 

Note too that all the behaviors above are new with the new SF version. I did have some odd behavior in the past versions but nothing that I couldn't live with.
Thanks,
Rod