I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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?

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

Hi Dale -

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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

---

I have used AccuTerm in limited fashion, (text boxes and lists), in my character based systems.  I would like under the GUI AccuTerm to make the conversion behave as now.  Example from events management:  Customer demographics enter customer number or keyword which brings up a list of customers.  I can see this clearly in the DEMO examples.  Change prompt for customer demographics I invite an <O>ptions and display a little window offering options like <R>entals.  If selected it lists the customers existing rentals.  Selecting a rental the calls the rental summary screen with options.  The <B>uildings option lists buildings on the rental.  Selection of a building shows the details of the building portion of the rental, offers options, one is <I>tems which allows entry of table, chairs, etc.  I can see the in CM the forms DETAIL, LOGIN, and MAIN all in the same program.  The event management would require 7 forms and I'm afraid the code would be overwhelming.  I hope someone can offer a way to do separate calls to different forms as I now do calling the subroutines passing and retrieving data items.

Dale

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?

---