MultiValue Tools

Dale Kelley posted 10-29-2022 08:43

Is there an AccuTerm forum I can join.  Is Pete Schellenbach somehow available?

ROCKETEER Mark Sapp posted 10-31-2022 09:36

Dale,

You'll find Accuterm is part of the MultiValue Tools sub-forum:
https://community.rocketsoftware.com/forums/multivalue?CommunityKey=9623ec16-9dfa-45ef-b0ef-482ea8980f44

ROCKETEER Peter Schellenbach posted 10-31-2022 19:32

Hello Dale -

There are 3 coding models available for AccuTerm GUI: standalone, dialog box subroutine, and multiple-application subroutine. The standalone model is the simplest, and most of the example programs use this model. Here's a link to the code model documentation: AccuTerm GUI Code Models

The dialog box subroutine model  most closely resembles the green-screen workflow you describe. You can create a GUI project, and when creating the boiler-plate code for the project, select "dialog box". The project can contain one or more forms, and all the forms must be "dialog" style. This form style is a "modal dialog" - only the most recently displayed form is active, any parent forms are disabled while a child dialog is open. The dialog forms can be nested to any depth. You can customize the argument list in the generated subroutine to pass any arguments in and out.

A couple of interesting notes. Make sure you do not call ATGUISHUTDOWN from any of your subroutines. This will close any open GUI forms. There is no harm omitting this call. Also, you can call a GUI dialog subroutine from a green-screen program.

Hopefully, the example programs will help you figure things out. There is a video tutorial that I made about 10 years ago. Its a bit out of date, but the concepts are still relevant. Here is a link: AccuTerm GUI Tutorial

Thanks, Pete

Dale Kelley posted 11-01-2022 07:23

I'm working on duplicating the MDI.MAIN model for a beginning menu.  When I generate the basic code for the MENU.FRM I'm confused about how to properly name the new code and which type of subroutine it should be.  Thanks Mark for the pointer.  And Peter, I'll go through the tutorials again.
Dale

Dale Kelley posted 11-02-2022 07:53

I've gotten my first MDI working, I have an exit button, a "run another GUI" button and a text box. I see that everything works except the "run another GUI"; it responds to being clicked or the text entry but I have not been ale to find an example that loads and activates another GUI that has worked.  I compiled the GUI to be called as an MDISubroutine.  Can you think of an example in any of the ACCUTERM BP's?
Dale

ROCKETEER Peter Schellenbach posted 11-02-2022 16:31

Hi Dale -

There are two approaches if you need MDI: standalone and multi-application. MDI is more complex than SDI, so I would recommend using SDI instead. Microsoft has long ago stopped using MDI in their apps like Excel. If you need to switch coding models, for example from MDI to SDI, you can rename your Pick BASIC program, then in the GUI designer, create new code using the other model, then edit the new code. In the wED Editor, you can open the previous version of the code (the program that you renamed) and copy/paste the event handlers you have already written into the new program.

There is a sample MDI project using multi-application coding model. Look in GUIBP for MDI.MAIN, GUISUB.MDI.MAIN.MENU, GUISUB.MDI.TREE.DEMO and GUISUB.MDI.GRID.TUTOR. Corresponding GUI projects are in GUIAPPS. MDI.MAIN.MENU is the main project and includes the MDI menu along with two forms. The MDI.MAIN program is the multi-application dispatcher, which relays events between each of the subroutines.

Note that the sample MDI project does not maintain state in the individual subroutines. In a real application, when you use the multi-application model, you likely will need to maintain state. Using a named COMMON for each subroutine is probably your best solution - just include any variables you need to persist between invocations of the subroutine in that COMMON.

The advantage of the multi-application model is that you can build large complex applications in small components handled by individual subroutines. But you need to manage the components at runtime so as to not exceed resources on the user's PC. Probably a safe limit to the number of forms open at one time is about 20.

As far as launching one GUI program from another GUI program, two things to keep in mind. If the launched GUI program is not a "modal dialog", then it may need to be modified to remove the call to ATGUISHUTDOWN so that when it ends, it does not shut down the calling program. Second, you should either hide (ATGUIHIDE) or disable (ATGUIDISABLE) the calling GUI program so the user cannot interact with it while the launched program is running. This ensures that events which may occur if the user tries to use the calling program (because he can still see it) those events will end up in the launched program, but that program will not recognize those events and simply discard them. This give the appearance that the system has "frozen". Remember, the Pick machine running these programs is single-threaded so only one program is actually running, any "parent" programs are stuck on the EXECUTE stack on the Pick side.

Thanks, Pete

Dale Kelley posted 11-03-2022 10:42

Thanks again Peter, I've made progress in calling a 2nd app and form from my menu button.  The screen size is reduced from that on the Designer.  There are some properties I can't see in the Designer but can see and set if I continue reading the GUI Library routines and hacking around with them.  I'm guessing I could set those properties from my code.
Dale

ROCKETEER Peter Schellenbach posted 11-04-2022 10:57

Hi Dale -
Yes, there are a few properties that are not available in the designer. You can set / retrieve any property from code. I'm not sure why sizing is different in designer and runtime. Did you adjust the scale mode for the app object? The default (characters) works pretty well and scales nicely on different monitor resolutions.
Thanks, Pete

Dale Kelley posted 11-04-2022 11:13

What finally made it behave was setting the application dimensions small and the vehicle profile screen larger.  Neat finding, I can load the same logic that sets up the same LIST.DIALOG call from my character screens and it works perfectly.  Still a lot to learn, . . . and I'm an old man, I may need to get some of that prevagen.
Dale

Brian Speirs posted 11-07-2022 14:07

As another form of assistance, go to www.rushflat.co.nz and download "Getting Started in OpenQM - Part 2". This mostly deals with creating a GUI application using AccuTerm. The book is in the process of being re-written, but it will probably be another year before I get it finished. However, it is still useful.

Cheers,

Brian

Dale Kelley posted 11-07-2022 15:41

I recall that when I installed AccuTerm on the server I did not do it properly.  Now I find that some AT and FT objects are not available and some of the GUIBP records show "New Record..." in the ED but are visible and editable in Linux (8).  I've tried patching and copying, no good results.  Should I just delete the ACCUTERM account, delete the directory and load it again from scratch?

ROCKETEER Peter Schellenbach posted 11-07-2022 15:51

Hi Dale -

Delete (or rename) the ACCUTERM account and starting fresh is probably your best bet.

Dale Kelley posted 11-08-2022 07:23

Brian, thank you for the publication.  I have downloaded the pdf and will dig in.  I see that you have agriculture applications.  I'm a poor little Tennessee dirt farmer with a few cows.
Dale

Dale Kelley posted 11-10-2022 09:29

I have been working with everything as MDI and done the menu, call the vehicle profile, load a vehicle, call the schedule list and call the schedule item maintenance passing my GUIARGS successfully.  However, when I set the values and check them my first text item displays a the calling GUIAPP overlayed on the passed text item.  Also except for maximizing the schedule application screen they appear reduced inside the screen of the calling program.  2 questions.  I did all my args extraction, file openings and value setting in the initial equates section.  Am I correct in thinking that some of that should be elsewhere?  Is a better alternative to make the menu and the vehicle profile standalone programs and limit subroutines to the instances where data is passed?