Xbasic Explorer?

[LeGauche]

I've run across references to the "Xbasic Explorer" in the A5V9 docs, but if it exists, I can't find it. Sounds VERY useful for learning Xbasic. Does Xbasic Explorer actually exist? If so, how does one really get at it? Thanks.

[Raymond Lyons]

Re: Xbasic Explorer?

I certainly have found it to be very useful, especially for learning.

Perhaps the most useful place to access it is with xbasic scripts on forms. In the script editor, go to the top menu and click Task List and then select Xbasic Explorer. Then click Objects, Windows and your form's name. This will give you all the objects on your form, and methods and properties not only for the form but also for every object on your form. Perhaps the most useful properties for fields are .value or .text. but you can learn a lot by playing around with many of the properties and methods.

Note that you can drag items into your script, dropping them wherever your cursor was in the script (usually on a blank line). For fields this item will begin with the name of the form, as in Form_name:fld_1.value (which you could set to "Smith" with Form_name:fld_1.value = "Smith". Because form names often change during development (mine do anyway) it is a good idea to change "Form_name:" to "Parentform:" (you can do all of them with a Search & Replace). This way the script will work no matter if the name of the form changes.

You can also access the Xbasic Explorer in the script editor when doing scripts from the Code Tab (same way as above), but of course from there you would not have any form objects.

Happy Learning!

Raymond Lyons

[LeGauche]

Re: Xbasic Explorer?

Mr. Lyons;

Thanks for your reply. I'm assuming that by "script editor" you mean "Code Editor". I'm not being pedantic here, I just want to make sure I'm following. I can follow your instructions only when the Code Editor form is on the screen. Only then does Task List contain the option "XBasic Explorer". Thanks again for taking the time to help a new learner.

[Raymond Lyons]

Re: Xbasic Explorer?

Hi Warren,

Yes, for someone new to all this I should have written "Code Editor" not "script editor." I might add that I recommend creating a test database with a table with all kinds of fields and then a form with fields, text boxes, buttons, etc. and then a new test button on which you can use the Xbasic Explorer to code all kinds of things relating to the other objects on the form. For example, with the push of the test button change the text in a text box depending on the value in a field. Or hide a field or text box. Or change the font for a field from black to blue. You get the idea--just play around to learn things that you can use later when working on a real application.

Have fun.

Raymond Lyons

[Raymond Lyons]

Re: Xbasic Explorer?

I certainly have found it to be very useful, especially for learning.

Perhaps the most useful place to access it is with xbasic scripts on forms. In the script editor, go to the top menu and click Task List and then select Xbasic Explorer. Then click Objects, Windows and your form's name. This will give you all the objects on your form, and methods and properties not only for the form but also for every object on your form. Perhaps the most useful properties for fields are .value or .text. but you can learn a lot by playing around with many of the properties and methods.

Note that you can drag items into your script, dropping them wherever your cursor was in the script (usually on a blank line). For fields this item will begin with the name of the form, as in Form_name:fld_1.value (which you could set to "Smith" with Form_name:fld_1.value = "Smith". Because form names often change during development (mine do anyway) it is a good idea to change "Form_name:" to "Parentform:" (you can do all of them with a Search & Replace). This way the script will work no matter if the name of the form changes.

You can also access the Xbasic Explorer in the script editor when doing scripts from the Code Tab (same way as above), but of course from there you would not have any form objects.

Happy Learning!

Raymond Lyons

While eating lunch it dawned on me that I should have added that in most contexts you need neither "Parentform:" or the form name ("Form_name:" in my example above). That is, in my example, fld_1.value = "Smith" is all you need. In any case, if you use drag and drop from the Xbasic Explorer, it can be a good idea (see above) to either replace the form name with "parentform:" or just delete the form name and use fld_1.value = "Smith".

Also note that in many cases form scripts can be moved to and be called from the Code Tab by a button on the form. Since such a script would be called from an appropriate form, even fld_1.value = "Smith" would still work, at least in V9. Whether you would want to or should move such scripts to the Code Tab is another question entirely and my answer would usually be "don't do it" unless you have a very good reason to do so.

Raymond Lyons

[MikeC]

Re: Xbasic Explorer?

In Addition, take a look at the Object Explorer. The copy to clipboard will give the correct syntax to use for various objects and their subelements...explicit or implicit.

[CALocklin]

Re: Xbasic Explorer?

... You can also access the Xbasic Explorer in the script editor when doing scripts from the Code Tab (same way as above), but of course from there you would not have any form objects.

Not totally true. IF you leave a form open (typically in design mode but it doesn't matter) while working in the code editor, then all those field objects will be shown in the xbasic explorer so you can add them to your script.

While eating lunch it dawned on me that I should have added that in most contexts you need neither "Parentform:" or the form name ("Form_name:" in my example above). That is, in my example, fld_1.value = "Smith" is all you need. In any case, if you use drag and drop from the Xbasic Explorer, it can be a good idea (see above) to either replace the form name with "parentform:" or just delete the form name and use fld_1.value = "Smith".

Also note that in many cases form scripts can be moved to and be called from the Code Tab by a button on the form. Since such a script would be called from an appropriate form, even fld_1.value = "Smith" would still work, at least in V9. Whether you would want to or should move such scripts to the Code Tab is another question entirely and my answer would usually be "don't do it" unless you have a very good reason to do so.

Here are some alternate thoughts. Neither method is "right". Just another way of looking at it.

Using "parentform": I prefer to include parentform (or topparent if necessary) simply because it is immediately obvious when I see something starting with those words that I'm working with an object on a form and not just a dot variable. Of course, it doesn't take a lot to figure it out - I just like to add those because it reduces the amount of thought I have to put into editing. I also think it makes it easier for me to find references to form objects - either visually or with a text search - because I can look for a known string - parentform. (I also cheat, typing "parentform" on my system is essentially one keystroke - <Ctrl-Alt-p>. I couldn't survive without my keyboard macro program!)

Moving script to the Code tab: I usually move any large script to the Code tab. Anything short and simple stays on the button/event. The real criteria are (1) how hard it will be to edit/debug the script and (2) how likely will it be to have to edit/debug the script. If I have to spend any amount of time debugging, it's much faster to "run a test, switch to the code editor, make changes, switch back to the form and start over" than to "run a test, switch the form to design mode, right click the object, open the editor, make the changes, save the form, switch to View mode and start over".

A third consideration for xbasic scripts would be "how badly do I want to protect the script". To me this is most critical for generic apps. For custom apps I seldom protect the code. If the script is something like "parentform.close()" then I certainly don't need to protect it. However, if it is a critical part of the application then I want to protect it from being tampered with. And if it's something that I consider complex enough that another developer would have a hard time figuring out how to do it, then I want to protect it so someone else can't use it to create their own competing application. Xbasic scripts can be password protected by simply putting a password on a commented first line like so:
'password MyPassword
It MUST start with 'password, including the single quote to 'comment' the line, and that must be followed by ONLY your password.

FWIW, it turns out that Action Scripts in the Code tab can also be password protected if you use the Script Passwords routine in my AIMS Grab Bag. This was a "bonus" because I had no idea it would work when I built the routine. The routine adds or removes passwords from all scripts and functions in the Code tab. On my system it takes about 8 seconds to add or remove all the passwords from 600 scripts. The only thing you need to remember with Action Scripts is that the password will be removed every time you edit the Action Script. Therefore, you must re-run the Script Passwords routine after editing Action Scripts if you want to keep them protected.