"Dialogs" in AppGraphics (Page 1 of 3)

Hi Jeff,

Would it be possible to use AppGraphics to create a windows dialog as a 'progress bar' such that within a loop the progress bar expands after each iteration, or is this beyond the capability of AppGraphics?

The purpose is to maintain a visual of a active routine while it's running in the background.  Another addition would be to add a 'quit' or 'exit' button to the progress bar to prevent infinite loops.

If AppGraphics has such a capability, could you explain by example?

Frank

Frank,

I've posted an example of a progress bar:

https://approximatrix.wordpress.com/201 … pgraphics/

You can download the source code at the end of the article.

Let me know if the above is what you had in mind.

I am new in graphics and can't write a routine to plot graphics. Do you have an example of the instruction set to make a plot of an equation or point data? Thanks.

Hi Jeff,
First of all the best wishes to the Approximatrix  crew and thanks for the fantastic tool SF!
Next there is a nice dialog dlgopenfile. I use it to open an file and also to select a directory by users. What I did not know is that this dlg also changes the working directory by this selection. I have to keep the first start up directory for use of some system settings in a new variable. The reason is that I have to make my program portable to other computers and other drives and directories. This can be done with the GNU intrinsic procedure getcwd. Is this the best solution or do you have an other suggestion?

Klaus,

I had thought I had answered your first question in the past, but perhaps I missed it.  The GETCWD intrinsic, while not part of the Fortran standard, is probably your best option.  There is no portable way to truly do what you asked.

I'll look into the beep, but I fear it is caused by windows itself.  The dlgmessage routine is a thin wrapper around the Windows MessageBox API call.

In regards to tabbing, supporting it would require a change to AppGraphics, but it should work.  I'll see that it is fixed.  The default would be to tab through controls in the order they are added.  Does that make sense?  Changing the order would definitely be non-trivial.

Hi Jeff,
Something is wrong with my design of a new dialog, but what ???
I declared some text boxes and check boxes as follows:

SUBROUTINE CSp_item_dlg
USE Appgraphics
use StrPartGlobals      ! contains declaration of derived parts
use W_ords_to_pixels    ! need because procedures in StrPartGlobals
    CHARACTER*4     STR(12)
    CHARACTER*4     STRG
    INTEGER dlg_screen, primary_fr
    integer box1, box2, box3, box4, box5, box6, box7, box8, box9, box10
    integer cbox1,cbox2
    integer Ignore, contin, settype
    logical*1 checked(3)
    Data checked/ 3*.false./
    external part_type_dlg
…...
…...test data....
…...
After setting the dlg window text and boxes are defined as follows:

settype = createbutton(315,20,70,20,"type", part_type_dlg)
  Call outtextxy(10, 20,'Title')
  box1 = createtextbox(10, 40, 180,16);    call Settextboxcontents(box1,CSP(isp)%title)     !Box1

  Call outtextxy(200, 20,'property')
  box2 = createtextbox(200, 40, 100,16);    call Settextboxcontents(box2,CSP(isp)%prop)     !box2
  Call outtextxy(310, 40,'(mm or profile)')

  Call outtextxy(10,60,'corrosion allowance')
  box3 = createtextbox(135, 60, 65,16);   call Settextboxcontents(box3,str(6))              !box3 -str(6)
  Call outtextxy(200, 60,'mm')

  Call outtextxy(10,80,' Material quality:')
  box4 = createtextbox(130, 80, 65,16);   call Settextboxcontents(box4,CSP(isp)%grd)        !box4

  Call outtextxy(10,100,'Part is on frame:')
  box5 = createtextbox(130, 100, 40,16);   call Settextboxcontents(box5,str(2))             !box5

  Call outtextxy(180,100,'Primary frame:');Write(strg,'(i4)')primary_fr
  box6 = createtextbox(270, 100, 40,16);   call Settextboxcontents(box6,strg)               !box6
  !preliminary to be found from the repeat rules

  Call outtextxy(10,120,'number of parts P+S:')
  box7 = createtextbox(130, 120, 40,16);   call Settextboxcontents(box7,str(3))             !box7

  Call outtextxy(10,140,'conection poin 1:')
  box8 = createtextbox(130, 140, 40,16);   call Settextboxcontents(box8,str(4))             !box8

  Call outtextxy(10,160,'conection poin 2:')
  box9 = createtextbox(130, 160, 40,16);   call Settextboxcontents(box9,str(5)) !if plate, otherwise disableed

  Call outtextxy(10,180,'profile rotation:')
  box10= createtextbox(130, 180, 40,16);   call Settextboxcontents(box10,str(5))!if profile, otherwise disableed

  cbox1 = createcheckbox (180,  180, 200,20,'Mirror x-dir', update1)
  cbox2 = createcheckbox (280,  180, 250,20,'Mirror y-dir', update2)

  Call checkboxsetchecked (cbox1,checked(1)) 
  Call checkboxsetchecked (cbox2,checked(2))

  Call outtextxy(10,200,'profile rotation anti clockwize against upright position')
  Call outtextxy(10,280,'Parts on current frame are repeated on every frame exept primary frame')

!___________ enable / disable parts depending on type ____________________
  Call enabletextbox (box6, .false.) !______________ also disable primary frame / no user input
select case (CSP(isp)%typ)
    CASE (101,111)
    Call enabletextbox (box10, .true.) !if plate
    Call enabletextbox (box9, .false.)  !if profile
CASE default
    Call enabletextbox (box9, .true.)!true.)
    Call enabletextbox (box10, .false.) !if plate
end select

    contin = createbutton(15,420,50,20,"OK", cont)
    Ignore = createbutton(65,420,50,20,"cancel", quit_dlg)
call loop
Call closewindow(CURRENT_WINDOW)
Call setcurrentwindow (initW)

Three odd behaviors:
Now Box 6 has to be disabled but the test program shows box 5 disabled
Independent on part type always Box9 is disabled
At least  only chekbox 1 can be checked/unchecked
There must be something wrong with the box numbers I suppose. But I cannot find what.
Debugging shows  12 unique numbers for all boxes!
Do you have any suggestion what I am doing wrong?

Klaus,

I've started debugging your issues, and I can address at least one of your problems immediately.  You described that only one check box can be checked/unchecked by the user.  This behavior is because of the width you've specified for both check boxes.  The first checkbox, cbox1, measures 200 pixels wide, meaning it is actually taking up space from x=180 to x=380.  The second check box, though, is being placed in this same space, at x=280.  I think your problem should go away if you change the code to:

    cbox1 = createcheckbox (180,  180, 99,20,'Mirror x-dir', update1)
    cbox2 = createcheckbox (280,  180, 99,20,'Mirror y-dir', update2)

Additionally, the overlap had caused drawing issues on Windows 10, but the above change fixes that as well.

I'm still looking at the incorrect box enable/disable behavior you're describing.

EDIT: added your callbacks to the checkbox changes that I had deleted in my code

Thanks Jeff,
The check box problem is fixed with your advice.

Klaus

Thanks Jeff,
I shall try it asap, but:
Unfortunately an other problem occurred: After installing version 2.35 all returns from child windows did no longer work unless that there was nothing changed! Sometimes a message came that there was no graphic window open or graphics where shown in an window for other tasks.
After reloading update 2.33 everything did it as suspected.
What is wrong? Is it a bug?  Ore have I to recompile all libraries  with 2.35 again??
Klaus

Jeff,
Here is additional info:
I installed 2.35 latest version again!
Without recompiling the main program, every thing is working well; after clean/rebuild the following happens:
The change of different windows with menus is OK. Even some dlg windows, but some others will not return to the calling procedure, i.e. my edit sheet; there is no more response; but it did work in2.33!
I shall look into my edit sheet and make an overview about all not working child windows. First question: is the ESC key working well; because he is the exit of my edit sheet.
Regards, Klaus

Klaus,

There is currently a major bug in message processing in AppGraphics that came about as a result of our adding the ability to tab between controls. We've fixed the basic issue, but the change is clobbering arrow keys (and possibly others) within an AppGraphics program.  We're working to fix everything, but I suspect that change is the origin of your problem.