Utilizing VB Script execution?

Deploying to Windows? Utilizing VB Script execution? This is the place to ask Windows-specific questions.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

tetsuo29
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 103
Joined: Thu Jun 07, 2007 1:30 am

Re: Utilizing VB Script execution?

Post by tetsuo29 » Mon Mar 01, 2021 8:21 pm

Although I am curious why do as alternate language would perform that much slower. Not curious enough to actually start using one of the newer IDEs, though.
Oh, it might not be that way in newer IDEs. I'm using LC 8.1.10 to write a new app for Windows XP. :lol:

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Utilizing VB Script execution?

Post by FourthWorld » Wed Mar 03, 2021 9:58 pm

bogs wrote:
Mon Mar 01, 2021 8:02 pm
FourthWorld wrote:
Mon Mar 01, 2021 7:40 pm
The alternateLanguage option was added much later, originally to accommodate Apple's AppleScript, which (like so much from Apple in those days) didn't use common conventions like stdIn/stdOut.
I have no idea what you are talking about. "do as language" along with "alternateLanguage" has been around since Mc 2.5 at least for Mac's appleScript. I assumed it was there since the beginning, although of course I have no way to find that out haha, I know appleScript was available since Hc of course.
HC was a very different beast.

MC didn't port to MacOS until many years after its Unix birth in 1992; IIRC first Mac builds came onto the scene in the mid-to-late '90s ('96/97?), and took quite a while for them to become stable with some of the trickier features like QT.

Don't let MC's version number throw you off: Dr Raney was very conservative with his version numbering. We often saw upgrades with significant features as point releases. The v2 series spanned almost a decade.
Of course, adding vbScript to the alternate languages means that Windows can now use it as well, but what is it your trying to say about stdIn/stdOut ? OSX certainly has that and last I heard, so does Windows.
macOS is now a Unix, but MacOS 9 and earlier were not. And now that macOS has shell, LC's shell function works on all three platforms.
Are you saying that because 'nix has it as well, that 'nix users should not be included?
It depends on what you mean by "included".

If you want a program to run another program, that's done with shell.

If you want to run AppleScript on Linux, you're out of luck, because of course that's Apple-specific. :)

And if you want a GUI control language similar to AppleScript and VBA on Linux, you're also out of luck, because AFAIK there's no common means of doing that. There's not even a common desktop. It took many years for the Open Desktop consortium just to agree on file association conventions (and they're not even good ones, IMNSHO); I'm not holding my breath for them to come up with a GUI control language both KDE and Gnome can agree on (if either even have one at all).

GUI IAC takes more than an OS mandate. It takes developers to adopt a common object model and hooks to allow controlling it. Proprietary OSes can do that, because one company controls everything and third-party devs just have to go along with whatever they say. Not so with FOSS OSes.

There was a time when Ubuntu was starting to promote Python for such a role, but the cat-herding of getting app devs on board made that impractical. It's a lot of work for a dev to take on just for a subset of power users running a single distro. Some use it such as GIMP and Blender, but not many. And AFAIK none of them have agreed on a common OS-level scripting interface for their embedded scripting options - other than shell, that is.
Or are you saying we should all drop that hokey stuff and not use it anywhere?
What is "hotkey stuff"?
Frankly, I'm fine with shell myself
Me too, and most Linux folk. It's a very with-the-grain way of working with the system, and LC integrates quite nicely.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Utilizing VB Script execution?

Post by bogs » Wed Mar 03, 2021 10:49 pm

FourthWorld wrote:
Wed Mar 03, 2021 9:58 pm
bogs wrote:Or are you saying we should all drop that hokey stuff and not use it anywhere?
What is "hotkey stuff"?
I dunno, what is hotkey stuff? that anything like ravioli? or is it more like galumpkey? :twisted:

While I'm mauling over that one -
hokey hō′kē
adj. - Mawkishly sentimental; corny.
adj. - Noticeably contrived; artificial.
adj. - phony, as if a hoax; noticeably contrived; of obviously flimsy credibility or quality
Hokey, as I was using it, was an adj. describing the "do as script / alternate language" feature of Lc. You can pick any of the 3 lines under it (or even all 3 together, really), which ever suits :D
FourthWorld wrote:
Wed Mar 03, 2021 9:58 pm
Don't let MC's version number throw you off: Dr Raney was very conservative with his version numbering. We often saw upgrades with significant features as point releases. The v2 series spanned almost a decade.
It doesn't throw me off, I just have no way to know what came before that, however, it would differ little even if I *did* know for a few reasons:
1. The topic is about alt. lang. features as applies to scripting

2. It doesn't matter how many years after Mc was conceived that it came about, AppleScript was the first supported iteration. ( I found out that it was apparently introduced in 1.1, and changed in 2.9 to include Windows).

BTW, the 1.1 is I assume pointing to Rev, but it could just as easily be pointing to Mc 1.1 :D I was just playing around in Mc 2.2, and it is there as well, but that is besides the point (on the top of my head.)

3. I sure wish the current release pace was at least half as conservative , although I can understand why it isn't.
FourthWorld wrote:
Wed Mar 03, 2021 9:58 pm
Of course, adding vbScript to the alternate languages means that Windows can now use it as well, but what is it your trying to say about stdIn/stdOut ? OSX certainly has that and last I heard, so does Windows.
macOS is now a Unix, but MacOS 9 and earlier were not. And now that macOS has shell, LC's shell function works on all three platforms.
Um, YOU brought up stdIn/stdOut, remember? The way you put it sure sounded like you were saying that OSX 'n Win have "alternateLanguage" capability because they don't have stdIn/Out, and 'nix *doesn't* have alt.lang. because it *has* stdIn/Out, and I was trying to figure out why you would even mention "stdIn/Out" since it has less than nothing to do with anything as all 3 desktop platforms have it.

It really *probably* would have been better to say what you said this time around... it doesn't apply to 'nix because no one knows what alt.lang to use for it since there isn't a standard one.

Myself, I tend to lean towards shell so none of the above really means diddly to me personally, and I'm so far back in the IDE versions I'm relatively safe from having to worry about any (so called) improvement that comes out.

I was only asking because your statement wasn't clear to me, but now it is (I guess).
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Utilizing VB Script execution?

Post by FourthWorld » Wed Mar 03, 2021 11:44 pm

bogs wrote:
Wed Mar 03, 2021 10:49 pm
Hokey, as I was using it, was an adj. describing the "do as script / alternate language" feature of Lc.
And that's why I shouldn't try to reply here without my reading glasses. I had misread that as being on-topic, like some of the hotkey utilities that rely on system-wide mandated scripting conventions. FWIW I don't think shell or other scripting solutions are hokey.
BTW, the 1.1 is I assume pointing to Rev, but it could just as easily be pointing to Mc 1.1
If it runs on any hardware you can still turn on, it's probably Rev. Their versioning began in the 20th century with 1.0, based on MC v2.4.2 or later, IIRC.

3. I sure wish the current release pace was at least half as conservative , although I can understand why it isn't.
Ah, but it wasn't so much pace that changed as the numbering scheme applied to each release.

The current versioning seems more in keeping with contemporary semantic versioning conventions, where three decimal-separated components are used to convey scope: left-most is for major changes; middle is for minor features; right-most for bug-fix-only releases.

Most companies stray a bit from those general guidelines now and then, and LC Ltd is no exception. But MC was in its own world, where even big features with a file format change were delivered in a point release. This gives an artificially low perception of scope to the audience, less communicative to both experienced devs who become surprised to discover the new file format, and to the market as well who then underestimates progress done on the code base.

Um, YOU brought up stdIn/stdOut, remember? The way you put it sure sounded like you were saying that OSX 'n Win have "alternateLanguage" capability because they don't have stdIn/Out, and 'nix *doesn't* have alt.lang.
What I wrote was:
The shell function was and remains the solution on platforms that support stdIn/stdOut, such as Unix on which this engine was born.

The alternateLanguage option was added much later, originally to accommodate Apple's AppleScript, which (like so much from Apple in those days) didn't use common conventions like stdIn/stdOut.
viewtopic.php?f=18&t=163#p202408

I didn't refer to either AppleScript or shell as "hokey" or necessarily inferior to one another. But since Apple switched from their own isolated set of OS conventions where AppleScript was born to adopting Unix conventions, we see them increasingly suggesting shell-oriented solutions to automating workflows where practical.

They're not apples-to-apples, though, despite early efforts from some corners within Apple to suggest ditching AppleScript altogether after the OS became Unix with OS X. They quickly discovered that a lot of publishing workflows are based on programs heavily invested in AppleScript, and automation is a must-have in some segments of that industry.

So Apple has come to understand that AppleScript must be at least maintained, and they don't mind where new apps adopt it. But you'll notice that a lot of automation solutions they suggest these days are shell apps glued together with bash.

It really *probably* would have been better to say what you said this time around...
Maybe. But whether I take the time to carefully craft a reply or thumb something together on my phone, the outcome is often the same: most of what I write here is ignored, and much of the remainder manages to be seen as wrong, whether it is or not. So I've just come to accept that the only people who think I'm a good writer are the book and magazine editors I've worked. Beyond that I just do what I can here in my spare time, sometimes it's helpful, sometimes not. No worries. It's just a forum post.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Utilizing VB Script execution?

Post by bogs » Thu Mar 04, 2021 12:46 pm

FourthWorld wrote:
Wed Mar 03, 2021 11:44 pm
BTW, the 1.1 is I assume pointing to Rev, but it could just as easily be pointing to Mc 1.1
If it runs on any hardware you can still turn on, it's probably Rev. Their versioning began in the 20th century with 1.0, based on MC v2.4.2 or later, IIRC.
Wow, really? How about running it on my current rig, in my current Os, as I reply to you here? With your name in the project AND the credits no less? Hmmmm <channeling the past ghosts of LC...>

Image

Hee hee.
FourthWorld wrote:
Wed Mar 03, 2021 11:44 pm
bogs wrote: Um, YOU brought up stdIn/stdOut, remember? The way you put it sure sounded like you were saying that OSX 'n Win have "alternateLanguage" capability because they don't have stdIn/Out, and 'nix *doesn't* have alt.lang.
What I wrote was:

The shell function was and remains the solution on platforms that support stdIn/stdOut, such as Unix on which this engine was born.

The alternateLanguage option was added much later, originally to accommodate Apple's AppleScript, which (like so much from Apple in those days) didn't use common conventions like stdIn/stdOut.
I know exactly what you wrote, I quoted it directly from your post silly. I did *not* say you said something was hokey, so I don't know where you got that one from, but I'll try to help you understand my confusion about what you said by putting parts of your quote in bold.

The alternateLanguage option was added much later, originally to accommodate Apple's AppleScript, which (like so much from Apple in those days) didn't use common conventions like stdIn/stdOut.

The parts not in bold don't really mean much, the date it was added doesn't mean a whole lot for instance, and we also already know that it was added to accommodate applescript since it says so everywhere it is mentioned in the docs, etc.

So when I read it, it looks to me like it says -
The alternateLanguage option was added to accommodate Apple's AppleScript, which didn't use common conventions like stdIn/stdOut.

The above implies that the alt.lang function was only meant for apple, which lacked stdIn/stdOut, which is fine as it stands.

However, alt.lang was expanded at some point (which I indicated up there in Rev 2.9) to include Windows vbscript. Why? What was the point? In your statement, it sure looks like your saying that alt.lang was solely for an OS that had no stdIn/stdOut. Windows sure did have stdIn/stdOut at that point in time, just as 'nix has. This is where I introduced 'hokey', because it sure looks hokey to me.

Now, if somehow you still don't get what I am saying, well, thats life I suppose. Since the post you wrote that started the question quoted my own post, where I merely indicated that
do as alternateLanguage may have some appeal for you these days...unless, of course, you use 'nix, which means you can't use this
I felt some clarification would be nice. Oh well, would be nice I suppose to have teleportation tech too hahhah.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Utilizing VB Script execution?

Post by FourthWorld » Thu Mar 04, 2021 5:52 pm

Let's simplify this:

What language exists for driving other GUI applications on Linux?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Utilizing VB Script execution?

Post by bogs » Thu Mar 04, 2021 7:20 pm

I don't see how we could do anything but make it more complicated at this point, unless you find something wrong with my statement as it stands, which I'll repeat again, was
do as alternateLanguage may have some appeal for you these days...unless, of course, you use 'nix, which means you can't use this
I do not see that it needs clarifying more than that.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Utilizing VB Script execution?

Post by FourthWorld » Thu Mar 04, 2021 7:42 pm

In short, you reminded alternateLanguages doesn't exist on Linux, and I reminded them that the shell function is a useful option.

I don't know why it takes us so many posts to say simple things on which we agree.

Good news: I have both a board game and a software product in development, so my time available for writing distracting posts here will be limited for a while.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Utilizing VB Script execution?

Post by bogs » Thu Mar 04, 2021 8:51 pm

That is terrible news, but I'm happy for you heh.

Me, I'm still waiting to see the script editor you were talking about :P
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Utilizing VB Script execution?

Post by FourthWorld » Thu Mar 04, 2021 9:06 pm

bogs wrote:
Thu Mar 04, 2021 8:51 pm
Me, I'm still waiting to see the script editor you were talking about :P
That's first.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Post Reply

Return to “Windows”