Discussions related to Visual Prolog
Frank
Posts: 22
Joined: 23 Nov 2014 20:41

resourse identifier constant

Unread post by Frank »

According to the help topics (7.4) about control identifiers, each control such as push button or list box should have
1) a "constant input box" to select a symbol or an integer that will be used as control identifier.
2) a "Text box" to enter a name for the button.

Moreover, iDE will automatically generates an integer and puts it in the resourceidentifiers.i file.

I am trying to put a radio button and a list box on a "form" but none of them has "Constant input box" and the list box does not have a "text box". In addition when I check the resourceidentifiers.i file none of the controls appear on the file.
I appreciate if you let me know how to assign an integer to the buttons and waht should I do to see their values in the resourceidentifiers.i file.

Thanks
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

resourceIdentifiers.i is only used for old vpi-style dialogs. The IDE cannot create such old dialogs and have note been able to do so for several releases. So the only way you can have a dialog for which resourceIdentifiers.i is relevant is if it is a very old dialog that you have retained from ancient time.

The properties of the controls are set in the property editor. See also Fundamental Visual Prolog - GUI.
Regards Thomas Linder Puls
PDC
Frank
Posts: 22
Joined: 23 Nov 2014 20:41

Thanks

Unread post by Frank »

You are absolutely right, it is about ancient dialog boxes. Congratulations to the depth of your knowledge. Those constants were so handy for simplifying the codes. It is unfortunate that they are no longer available.

Thanks
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post by Thomas Linder Puls »

I don't see how such constants can be used in code simplification.
Regards Thomas Linder Puls
PDC
Frank
Posts: 22
Joined: 23 Nov 2014 20:41

Unread post by Frank »

One way would be to use the assigned constants values in the resourceidentifers.i to capture which buttons, radio-buttons, etc. have been selected by the user, instead of using the lengthy names of the controls. Maybe I am wrong!
Thanks
Paul Cerkez
VIP Member
Posts: 106
Joined: 6 Mar 2000 0:01

Unread post by Paul Cerkez »

Frank,
I did something similar to what you are talking about approx. 20 years ago when I had to ensure that data values from user selections (e.g., radio buttons, specific text fields) being stored would always map back to the same control across all subsequent releases of the application. It was a critical safety application.

Earlier versions of VIP would rebuild the id constants list every time you compiled the application and it became a nightmare to keep the mapping consistent across builds. As long as you didn't add or remove a control all was good but as soon as you did, the constants list changed. For the work I was doing at the time, this approach worked very well. It was tedious to maintain if there changes to controls but if the number of controls were not modified, the SW was easy to maintain. As soon as users requested a change, effort increased due to maintaining the resources constants list and associated mapping.

What I do now is much 'simpler' and while it has a little bit more code, it is much easier to maintain. When I retrieve or save my data it is from an internal structure and I know what each element in that structure is and where it is located. I use a 'parent' predicate to read the data from the store, parse through it and each element then gets passed to a 'child' predicate that handles all interfaces with the control itself. The reverse is true when going from the control to the data store. I found this approach robust to changes and I no longer had to worry about the constants table (and dependency mapping) for controls. I could also add, remove, and modify controls as I needed with little impact to others.

If I needed specialized processing on a particular control (very common for the application I was doing), I simply added what was needed to the appropriate 'child' predicate.

It took a little while to complete the switch over but the application is much more stable and easier to maintain. The end result was decoupling of the code base from the data.

it may seem like a daunting task right now but in the end it will be worth it.

One final point, you can name the controls anything you want. You don't have to use the VIP suggested ones. Although I sometimes use my own naming conventions for very specific sections of code, I usually use the VIP suggested ones because it is easier to maintain the software.
AI Rules!
P.
Frank
Posts: 22
Joined: 23 Nov 2014 20:41

Unread post by Frank »

Thank you so much Paul for your detailed response. I'll try to implement your suggestions.
Best,
Frank
Paul Cerkez
VIP Member
Posts: 106
Joined: 6 Mar 2000 0:01

Unread post by Paul Cerkez »

You're welcome.
AI Rules!
P.
Post Reply