Action Scripting A "Steeping Stone" - Really? Then why......

[SNusa]

I just don't get it... A5 training courses frequently support/promote the usage of action scripting as a "stepping stone" to hard coding X-basic. This makes sense.....

However: These three (3) limitations within the a5 GUI significantly (IMHO) interfere with the progress of learning:

1.) SEARCHING FOR THE CORRECT ACTION SCRIPT
When trying to pick the correct action script (once you realize you have the wrong one in the list) why isn't there a "back button" so you don't loose your place looking???

2.) CUSTOMIZING X-BASIC ATTACHED TO A FORM OBJECT EVENT (Form object events originally created & converted from Action Scripting into X-basic.)

When converting an action script into Xbasic, I first duplicate it. (convert one to X-basic, and the disable the other one)
The problem/limitation occurs when editing the converted X-Basic. (Sttached to a form's object event, ie: a button) Because the editor is modal, access is not granted to the drag and drop X-basic Explorer for proper code formatting. (which also includes the Function Explorer) ~This makes learning coding frustrating, tedious, and prone to syntax errors......

3.) RESTORE PRIOR VERSION FUNCTION LIMITATION (I suppose this is minor by comparison, but WHY NOT?)
This feature is not available on Operations, and more importantly, the Code tab. ~ Just sayin'

A while back, I made an inquiry as to the first two. I was told they were not important. Maybe not for advanced / professionals, but nevertheless - everyone begins somewhere, right.....

I can't tell you how many times (during the steep learning curve) that I became frustrated due to the above limitations.
Presently, I still use some button event coding with action scripting as a basis before converting to X-basic. (as many others, I am sure do too) Even with experience, this still presents itself to be detriment to productivity! For what it's worth, even the a5 instructors get twisted up sometimes (on syntax) when they generate code by hand without referencing the the X-basic Explorer.....

Does anyone else agree???

[MoGrace]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

I haven't used AS much other than to peek at the code created for queries. But when I do for an object event, it is very easy to create a new XB script in the code editor to copy and paste the xbasic for editing and then paste it into an inline AS, comment out the other AS lines, save the AS script and not save the Untitled script. And when you get your snippets of XB code as you like them - save them to the Code Library!

[Ted Giles]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Interesting discussion.
I use AS most of the time to avoid coding. Using AS usually gets it right first time.

[SNusa]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Interesting discussion.
I use AS most of the time to avoid coding. Using AS usually gets it right first time.

Late last winter, I finally (after years) "took the plunge" and subscribed to a5. Fully committed, I invested "crazy time" watching, re-watching, taking notes and learning a5 from the ground up using the a5 training courses videos....

Years prior, I had uncovered a handful of significant issues (bugs) which were addressed and corrected. I just never had the time to pull it all together...... (other primary business obligations always interfered)

During much of my learning process, frustrations (which almost caused me to give up a5 forever) was: 1.) Not knowing if my problems were bug related, and 2.) Not being able to easily find what I needed to get a5 to do exactly what I wanted to.

In my particular situation, I'v been purchasing a5 softwarae since v4 DOS. Needless to say, I spent spent a significant amount of $$ throughout the years hoping that the next version would get better and easier to use. It definitely got better, but easier - that's highly subjective one's interpretation.

As advanced, capable (and complicated) as a5 is, it seems to me it would behoove Alpha Software to make a5 as easy as possible for "entry level users" (newbies) to "sink their teeth into." To some degree, they (a5) have not done this. What they have done (instead) is create a plethora of tools in one nice package which provides the accomplished virtually unlimited capabilities.

It's important to note that: While their strategy may be great for the professional, it's bad for new users! Adding to this problem, is the reality of no longer having a help file. (I detest using the WIKI! ~ IMHO, it's way too hard to retrieve precisely what you're looking for in the web based help.)

Anyways, during my own "trials and tribulations" (last winter) I presented several criticisms/suggestions/ideas to Sewlyn. (the basis of my original post) To make a long story short, he did not see the significance of any of this, and indicated that the suggestions were of little importance. From his perspective, that makes complete sense. Obviously, Selwyn is at the forefront of development, and didn't (doesn't/can't) see the implications from a "new users perspective."

In our email "discussions", Selwyn also indicated that: Adding a "back" button to the action script selection box would also require a lot of work/re-coding. (Under the circumstances, his response both surprised and concerned me a little bit! My initial thoughts were, and still are: "What, did you guys loose the original code for that part of the a5 program? It hasn't changed in a decade!") ~ STRANGE!

This kind of "thinking" on these matters certainly doesn't pull new users "into the platform." ~ Instead, it pushes them away. I nearly gave up, and I'm glad I didn't. Even so, it took a lot of work just to get here. And it would have been easier (and "lessened" the steep learning curve) with a few minor changes ("fixes" as I call them) to the program. And even today, these are still features I "am wishing for."

Actually, on a related note: The whole "renewable subscription plan concept" can kind of be seen as a temporary fix (IMHO) to growing a renewable & young user base...... If I was a5, I'd want both subscriptions and a ton of new users.

PS: Don't get me wrong regarding this post. I like a5. (Enough so that I've been buying it for years.) But I am certain that many others in my shoes would have just given up completely, or tried something "easier."

[SNusa]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

In submitting my previous post, I just had an epiphany......

How about adding one option to the right click menu in a5 (when user right clicks on a Action script) to do the following:

This option would (in one step) "Convert Action Script to Code on Code Tab" and call script via Script_Play_Local().....
(after prompting for user to provide a name for the script) ~ That's one workaround to problem #2......

Then, all the code in need of editing would get full support of the a5 development tools with just a few clicks!

[Ray in Capetown]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Also just saying...

1.) SEARCHING FOR THE CORRECT ACTION SCRIPT

The frustration is probably more from trying just not succeeding. When I try these I now note the AS name and just type the first letter to get (close) back to it in the list of options.

2.) CUSTOMIZING X-BASIC ATTACHED TO A FORM OBJECT EVENT (Form object events originally created & converted from Action Scripting into X-basic.)

That is a drag, but the best advice given on this site is not to use script attached to forms but the form calling scripts or functions saved as code. I still code the event on buttons during development but calling independant code (when I do) does make the process a whizz. (Note to myself - again). Also later access to code you previously created becomes MUCH easier

When converting an action script into Xbasic, I first duplicate it. (convert one to X-basic, and the disable the other one)
The problem/limitation occurs when editing the converted X-Basic. (Attached to a form's object event, ie: a button)

There is an option to use the code editor and there it stays after.

3.) RESTORE PRIOR VERSION FUNCTION LIMITATION (I suppose this is minor by comparison, but WHY NOT?)
This feature is not available on Operations, and more importantly, the Code tab. ~ Just sayin'

Code editor has one of the best roll-backs I've seen, especially with V10

[MoGrace]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Whenever I see good examples posted here in the forum, I create a sub directory in my test directory for the database so I can have my own 'library' to search thru. I seldom use the Wiki either for the same reason - not being able to find what I am looking for with a clear enough example, but I still use my v9 help file. Someone ought to come up with a way to annotate that file, then I could add my own notes to it. Anybody...?

[Ted Giles]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

I went through the angst barrier when changing from V4 to Alpha for Windows.
The agony of trying to go from DOS to Windows was horrible
Much more relaxed now, and still using the tools supplied as far as possible without using code. After all Alpha is still sold as a no programming application.
Where I can't find a function to do what I need as opposed to what I want - I'll try and code with Forum assistance.

[SNusa]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Also just saying...

The frustration is probably more from trying just not succeeding. When I try these I now note the AS name and just type the first letter to get (close) back to it in the list of options.

That is a drag, but the best advice given on this site is not to use script attached to forms but the form calling scripts or functions saved as code. I still code the event on buttons during development but calling independant code (when I do) does make the process a whizz. (Note to myself - again). Also later access to code you previously created becomes MUCH easier

There is an option to use the code editor and there it stays after.

Code editor has one of the best roll-backs I've seen, especially with V10

I've got the action scripting pretty much all figured out. The frustration is largely the result of "coming to terms with the fact that:" It's almost easier to code much of the stuff in X-basic directly without wasting time looking for it first. (Looking through the Action Script scripts, I sometimes feel like a "hamster (or gerbil) spinning on a wheel!") ~ It shouldn't have to be like this!

Aside from your "note to myself - again" comment, which indicates you are also inclined to "attach scripts" directly to form events.... (which reaffirms my position on that subject).......

Your last two responses need clarification:
(So please correct me if I'm wrong.)

The option to use the code editor (after converting AS to X-basic) prohibits you from gaining access to tools like the X-basic explorer due to "modal" implementation of the editor for converted action scripts. To get around this, you must copy the code, save it as an external script in the code tab, and call it using the method script_play_local().

As for the Code editor roll-back feature.... I must be missing something here. When I edit a X-basic based script (on the code tab) and the save it...... It's final. If I haven't backed it up, and I mess up the code, there is no getting back/reverting to the old code..... (Where's the rollback feature here? I might be missing something.)

[Tom Cone Jr]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

The option to use the code editor (after converting AS to X-basic) prohibits you from gaining access to tools like the X-basic explorer due to "modal" implementation of the editor for converted action scripts. To get around this, you must copy the code, save it as an external script in the code tab, and call it using the method script_play_local().

This hasn't been my experience.

For example, when working with the onChange event for an object in a form layout, if the script is initially written using AS, then you can convert the script to xbasic whenever you want using the Code Menu choice. Once converted the Code Editor will open the script conventionally and you can get to the Xbasic Explorer using the Task List Menu choice.

In fact, the Xbasic Explorer is available even when editing an AS directly. Use the Task List menu option.

[SNusa]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

This hasn't been my experience.

For example, when working with the onChange event for an object in a form layout, if the script is initially written using AS, then you can convert the script to xbasic whenever you want using the Code Menu choice. Once converted the Code Editor will open the script conventionally and you can get to the Xbasic Explorer using the Task List Menu choice.

In fact, the Xbasic Explorer is available even when editing an AS directly. Use the Task List menu option.

Hi Tom!

Try this: Right click on a form button and create an on push action event using action scripting. Then convert the AS (attached directly to a form object event) into X-basic. Finally, right click on the "inline X-basic" and select edit.

The X-basic opens in a small modal window. Within that window, there is a button enabling me to "zoom to re-sizable window" to edit the code in a larger window. When doing so, this larger window is still modal, and you can't use any of the tools outside this window. I don't think it should be like this..... Please confirm.

Note: Once converted, the only way to access this X-basic is via the action scripting window.....

[Al Buchholz]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Robert

Sounds like you are editing xbasic in the inline xbasic Action Scripting. It can be limiting.

You can copy/save to it's own xbasic script where the editor is different and all of the tools are available.

Your ultimate destination is to build a function that accepts arguments and returns a result.

[SNusa]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Robert

Sounds like you are editing xbasic in the inline xbasic Action Scripting. It can be limiting.

You can copy/save to it's own xbasic script where the editor is different and all of the tools are available.

Your ultimate destination is to build a function that accepts arguments and returns a result.

I know this. I am editing inline, and I couldn't agree more.
But I have a valid reasoning behind my methods ~ It helps me learn by example, and absorb concepts at a higher pace.*

However, when learning and trying new things (by example especially) like is recommended in all the a5 courses, I still sometimes find myself attaching action scripts to form events as my starting point. (and I don't want to waste a lot of time setting all this up to "try new things.") Not having this ability just adds to the learning curve / difficulty. (It does for me anyways!)

*Note: Full access to editing tools from within converted action scripting is also helpful when trying to debug someone elses "program." Last year (as a test of my understanding) I solved a problem where action scripting was the culprit, where it ultimately was using a .value (which wasn't working for reasons un-known by all). After a ton of trial and error, (because I couldn't drag & drop code from the X-basic explorer)... "On a hunch, I tried replacing the .value reference with .text in the action script (after converting to X-basic) and voila..... Problem solved.... (Starcs)

[Tom Cone Jr]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

Robert, I agree with Al. If I follow the steps you describe I see that you haven't left the Action Scripting editor. Instead if you're working with an "action" that consists of "inline" xbasic. Convert the whole script to xbasic from the Code menu, instead. There's no reason whatsoever to save your script to the code page to get to the Xbasic Explorer. You just have to convert the "script" to xbasic.... not the "action".

[Ray in Capetown]

Re: Action Scripting A "Steeping Stone" - Really? Then why......

As for the Code editor roll-back feature.... I must be missing something here. When I edit a X-basic based script (on the code tab) and the save it...... It's final. If I haven't backed it up, and I mess up the code, there is no getting back/reverting to the old code..... (Where's the rollback feature here? I might be missing something.)

I stand corrected on this. I keep my original on the button event, if necessary with an END in front of it. (when i have saved it as code.) thats the rollback version.
As was pointed out in a previousl post - if a form is lost, so are the form based scripts. I dont have first hand experience of this - thankfully.