LC's standalone Maker

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LC's standalone Maker

Wprothero
Folks:
Sorry for this long email. I hope that someone who has submitted apps to the Apple store, with success, will give me a bit of help, as I’ve searched the help files and tutorials and I haven’t found anything about the details of using non-livecode files in an application.

The description of my problem is much longer than my questions.

I’ve been having some trouble with the way the standalone maker organizes external non-livecode data files and wonder if anybody else has had problems. I purchased App Wrapper 3 and have had some interactions with Sam, the author, and sent some wrapped and un-wrapped examples and got some feedback. The reason is because, although the applications work, his installer and zip output don’t work.

FYI, I’m only building a MacOSX standalone and am on OSX Mavericks. Currently using LC 7.0.1 RC3

Here is Sam’s response:
----------------------
When it comes to bundles, there’s a golden rule (or many more).

Main Executable application goes in the /MacOS folder.
Additional executable code goes in /Frameworks, /Plugins, or /Helpers.
Non executable files should go in /Resources

So in theory your data files should be in the resources folder and the externals that LiveCode create should be in PlugIns (especially as they roughly conform to a bundle).

It seems like LiveCode likes to have the data files in the /MacOS folder, you might be able to fool it by using a relative symbolic link, then again you may not.

Have you spoken to any other LiveCode users on their forums or support about this?
———————

The standalone builder has a nice place to specify the location of external files. The window is labeled “non-stack files in the application”. In my development environment, the “files" folder is at the same directory level as the myApp.livecode application. Within the “files” directory are numerous sub-directories containing various binary, text and other data files. These are not livecode stacks. I just have one line in this field: “files/*”  (no quotes).

The standalone builder, after the standalone is built, creates an empty “files” directory in the Contents/MacOS folder with empty subdirectories that are the same ones in my “files” directory.  In the “Resources” directory, it puts my “files” directory, with all subdirectories and data within, into the “Resources/_MacOS/files directory.

This structure appears to confuse App Wrapper 3, and Sam worries that Apple will not accept my application because all non-executable files must be in the Resources folder. But, the bundle created by App Wrapper 3 does work. The installer package and zip output create installed executables that cannot find my external data files. But, that’s not my main question here.

My application does work, after I made the needed code modifications to allow for the change in file structure that the standalone builder creates in the resulting bundle.

Questions about the application package built by the standalone builder:
1) Am I safe to just delete the empty folders in the “MacOS” folder to prevent Apple from thinking there is non-executable code within?

2)Why are the empty “files” folders in the MacOS folder, in the first place?

3) Are there complexities or anything else I should know about the use of external, non-livecode data files?

Thanks for any help and information.

Bill

William A. Prothero
http://es.earthednet.org/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: LC's standalone Maker

Trevor DeVore
On Sat, Dec 6, 2014 at 11:38 AM, William Prothero <[hidden email]>
wrote:

> My application does work, after I made the needed code modifications to
> allow for the change in file structure that the standalone builder creates
> in the resulting bundle.
>
> Questions about the application package built by the standalone builder:
> 1) Am I safe to just delete the empty folders in the “MacOS” folder to
> prevent Apple from thinking there is non-executable code within?
>
> 2)Why are the empty “files” folders in the MacOS folder, in the first
> place?
>
> 3) Are there complexities or anything else I should know about the use of
> external, non-livecode data files?
>

Bill,

If you are using 6.7 or 7.0.1 (which it sounds like you are) the take a
look at the "Non-executable file redirection on Mac" section of the
Release Notes.pdf. That explains a recent change made to the engine and the
standalone builder so that non-executable files (e.g. stack files) can be
moved outside of the MacOS folder. This is why you are seeing the
Resources/_MacOS directory.

Do not delete the empty folders in the MacOS directory. The engine relies
on them and Apple doesn't seem to care. I have successfully submitted an
app to the MAS using this file/folder structure.

--
Trevor DeVore
ScreenSteps
www.screensteps.com    -    www.clarify-it.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LC's standalone Maker

J. Landman Gay
In reply to this post by Wprothero
On 12/6/2014, 10:38 AM, William Prothero wrote:

> Here is Sam’s response:
> ----------------------
> When it comes to bundles, there’s a golden rule (or many more).
>
> Main Executable application goes in the /MacOS folder.
> Additional executable code goes in /Frameworks, /Plugins, or /Helpers.
> Non executable files should go in /Resources
>
> So in theory your data files should be in the resources folder and the externals that LiveCode create should be in PlugIns (especially as they roughly conform to a bundle).
>
> It seems like LiveCode likes to have the data files in the /MacOS folder, you might be able to fool it by using a relative symbolic link, then again you may not.
>
> Have you spoken to any other LiveCode users on their forums or support about this?

LiveCode has already dealt with this and that's why you see two folder
structures. See the release notes for LC 6.7 under the heading
"Non-executable file redirection on Mac" which contains a full
explanation. If you aren't building with 6.7, you'll need to do that.

To preserve backward compatibility while still conforming to the new iOS
rules, an empty folder structure is created in the older location, and
the actual non-executable files are moved to Resources where Apple wants
them to be. The engine will look in both places so that your existing
scripts will work without errors.

I trust the team to know what Apple will accept, so I think you are
probably okay, though the explanation in the release notes doesn't
mention plugins so I'm not sure about those (you could ask support.) Do
not delete the empty folders or change anything in the bundle though.
The engine needs those to find your files.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LC's standalone Maker

J. Landman Gay
In reply to this post by Trevor DeVore
On 12/6/2014, 1:46 PM, Trevor DeVore wrote:

>
> If you are using 6.7 or 7.0.1 (which it sounds like you are) the take a
> look at the "Non-executable file redirection on Mac" section of the
> Release Notes.pdf. That explains a recent change made to the engine and the
> standalone builder so that non-executable files (e.g. stack files) can be
> moved outside of the MacOS folder. This is why you are seeing the
> Resources/_MacOS directory.
>
> Do not delete the empty folders in the MacOS directory. The engine relies
> on them and Apple doesn't seem to care. I have successfully submitted an
> app to the MAS using this file/folder structure.
>

You're quicker on the "Send" button than I am. :)

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: LC's standalone Maker

Wprothero
Jacqueline and Trevor:
Thank you, thank you for the info.
BTW, I did manually delete all of the empty folders and my app still found the data files. BUT, I had already programmed the file system to look in the new place. BUT, I also haven’t tried to do an iOS app yet, so probably best not to delete those empty folders, as you and recommend.

Best,
Bill

On Dec 6, 2014, at 11:55 AM, J. Landman Gay <[hidden email]> wrote:

> On 12/6/2014, 1:46 PM, Trevor DeVore wrote:
>>
>> If you are using 6.7 or 7.0.1 (which it sounds like you are) the take a
>> look at the "Non-executable file redirection on Mac" section of the
>> Release Notes.pdf. That explains a recent change made to the engine and the
>> standalone builder so that non-executable files (e.g. stack files) can be
>> moved outside of the MacOS folder. This is why you are seeing the
>> Resources/_MacOS directory.
>>
>> Do not delete the empty folders in the MacOS directory. The engine relies
>> on them and Apple doesn't seem to care. I have successfully submitted an
>> app to the MAS using this file/folder structure.
>>
>
> You're quicker on the "Send" button than I am. :)
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

How to Quit with a button

Wprothero
Folks:
I don’t know if this is needed anyway, but I have a button on one of my screens whose intention is to quit the application. The code is;

on mouseUp
        send “quit” to me in 0 seconds
end mouseUp

This crashes the application. The menu that the standalone creates, in the menu bar also has a quit choice, and the app does not crash.

So, is there a way to quit with a script? Or, is it just poor practice to do it this way and make the user use the menubar menu.

I’m on Mavericks, LiveCode 7.0.1 rc3. It has worked this way for several versions, and on V7.0, it crashed  even from the menubar menu.

Thanks,
Bill

William A. Prothero
http://es.earthednet.org/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Colin Holgate-2
Try this instead:

on mouseup
    quit
end mouseup

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Wprothero
Colin:
I did try that and it crashed the app too. That’s why I tried to delay the quit until it got through doing the mouseDown handler.
Bill
On Dec 7, 2014, at 3:25 PM, Colin Holgate <[hidden email]> wrote:

> Try this instead:
>
> on mouseup
>    quit
> end mouseup
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Colin Holgate-2
A bare bones test seems not to crash. Look for any handlers you have that are still doing something at the time you quit.

BTW, I was testing the idea with v7.01 rc3.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Wprothero
Colin:
I tried closing the browser window (on the card where I had the quit button) and it still crashes.
BUT, I did a test stack, made a standalone, and the quit button works. Hmmmmm. Wonder what it could be. My application stack is pretty big and complex, but ….. I don’t think any handlers are still running. There are a bunch of substacks.

I’ll try “Stop using” commands to get the substacks out of memory. BUT, why won’t the button work when the toolbar menu does. Obviously, there’s a difference in the way each works. It’s a mystery.
Bill

On Dec 7, 2014, at 4:14 PM, Colin Holgate <[hidden email]> wrote:

> A bare bones test seems not to crash. Look for any handlers you have that are still doing something at the time you quit.
>
> BTW, I was testing the idea with v7.01 rc3.
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Jim Lambert
In reply to this post by Wprothero

> Prothero wrote:
>
> why won?t the button work when the toolbar menu does. Obviously, there?s a difference in the way each works.

What happens if you

doMenu “Quit” from menu [appName]

?


Jim Lambert
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Ray Horsley-2
I just issue the command "quit".  You might consider saving first or, if
you don't want any interruptions, locking messages first.

On 12/8/2014 2:04 PM, Jim Lambert wrote:

>> Prothero wrote:
>>
>> why won?t the button work when the toolbar menu does. Obviously, there?s a difference in the way each works.
> What happens if you
>
> doMenu “Quit” from menu [appName]
>
> ?
>
>
> Jim Lambert
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Wprothero
Ray and Jim:
Tnx for the suggestions. Tried both. I did lock messages prior to the quit statement. I couldn’t get the toolbar menu to fire on quit. The menu is “PT_Explorer” and the item I want is “Quit PT_Explorer”. So I did
domenu “Quit PT_Explorer” of menu “PT_Explorer”

I got no response from the doMenu command, so perhaps I needed to include the shortcut key in the name? Anyway, I haven’t fully tried destroying all my substacks before trying to quit. The quit command does work in a bare stack with no other code, tho.

Tnx for the suggestions.

Bill

On Dec 8, 2014, at 9:29 AM, Ray <[hidden email]> wrote:

> I just issue the command "quit".  You might consider saving first or, if you don't want any interruptions, locking messages first.
>
> On 12/8/2014 2:04 PM, Jim Lambert wrote:
>>> Prothero wrote:
>>>
>>> why won?t the button work when the toolbar menu does. Obviously, there?s a difference in the way each works.
>> What happens if you
>>
>> doMenu “Quit” from menu [appName]
>>
>> ?
>>
>>
>> Jim Lambert
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Richard Gaskin
In reply to this post by Wprothero
William Prothero wrote:

> I got no response from the doMenu command, so perhaps I needed
> to include the shortcut key in the name?

DoMenu is pretty limited in LiveCode.  It was necessary in HyperCard
because that language wasn't rich enough to build an entire IDE in, so
the only way you could invoke some of the IDE features was through
"doMenu" as a sort of catch-all.

In LiveCode of course the IDE is make in its own language, so anything
you see in the IDE can be done more directly in your own stacks than
having to rely on a generic catch-all.

If you do need to trigger an IDE menu item, you can dispatch a menuPick
handler to the relevant menu button in revMenubar with the name of the
menu item as its param.

But quit is very essential - every app needs it - so that's built right
into the language with the "quit" command.

If you need to do any processing before the app actually quits, you can
trap the shutdownRequest message.

--
  Richard Gaskin
  Fourth World Systems
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter: http://twitter.com/FourthWorldSys

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Wprothero
Richard:
Thanks for the input. I’ll stop messing with the doMenu approach. I’ve tried a number of things to get my app to shut down without crashing the app. I know it must be possible because the toolbar menu quits fine. I may just stop trying to use a script to quit. It’s not essential since the toolbar menu quits fine. Anyway, I’ve tried locking messages, closing all substacks, delaying the “quit” with a send command, and it crashes no matter. But, a bare stack works fine. I wonder if I’ve come against some other bug in V7.0.1 that the quit command triggers. Anyway, it’s too complex for me to worry about at this stage, so unless there are other bright ideas about what might be happening, I’m going to remove the quit button.
Best,
Bill

On Dec 8, 2014, at 1:13 PM, Richard Gaskin <[hidden email]> wrote:

> William Prothero wrote:
>
>> I got no response from the doMenu command, so perhaps I needed
>> to include the shortcut key in the name?
>
> DoMenu is pretty limited in LiveCode.  It was necessary in HyperCard because that language wasn't rich enough to build an entire IDE in, so the only way you could invoke some of the IDE features was through "doMenu" as a sort of catch-all.
>
> In LiveCode of course the IDE is make in its own language, so anything you see in the IDE can be done more directly in your own stacks than having to rely on a generic catch-all.
>
> If you do need to trigger an IDE menu item, you can dispatch a menuPick handler to the relevant menu button in revMenubar with the name of the menu item as its param.
>
> But quit is very essential - every app needs it - so that's built right into the language with the "quit" command.
>
> If you need to do any processing before the app actually quits, you can trap the shutdownRequest message.
>
> --
> Richard Gaskin
> Fourth World Systems
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> Follow me on Twitter: http://twitter.com/FourthWorldSys
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Http://es.earthednet.org
Reply | Threaded
Open this post in threaded view
|

Re: DoMenu

Alain Farmer
Hello Richard,I disagree with your conclusion that DoMenu was necessary in HyperCard because that language wasn't rich enough to build an entire IDE in.DoMenu was an integral part of HyperCard's ease-of learning-to-program.One command (doMenu) versus many commands to learn/use/remember.Part of this paradigm: you can literally script something as-you-would-do-it-as-a-user.For power-users, you could intercept & handle doMenu, add-to-it-then-pass or even re-define it.For what it's worth,Alain

   
On Dec 8, 2014, at 1:13 PM, Richard Gaskin <[hidden email]> wrote:

> William Prothero wrote:
>
>> I got no response from the doMenu command, so perhaps I needed
>> to include the shortcut key in the name?
>
> DoMenu is pretty limited in LiveCode.  It was necessary in HyperCard because that language wasn't rich enough to build an entire IDE in, so the only way you could invoke some of the IDE features was through "doMenu" as a sort of catch-all.
>
> In LiveCode of course the IDE is make in its own language, so anything you see in the IDE can be done more directly in your own stacks than having to rely on a generic catch-all.
>
> If you do need to trigger an IDE menu item, you can dispatch a menuPick handler to the relevant menu button in revMenubar with the name of the menu item as its param.
>
> But quit is very essential - every app needs it - so that's built right into the language with the "quit" command.
>
> If you need to do any processing before the app actually quits, you can trap the shutdownRequest message.
>
> --
> Richard Gaskin
> Fourth World Systems
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> Follow me on Twitter: http://twitter.com/FourthWorldSys
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

 
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Jim Lambert
In reply to this post by Wprothero
I suggested doMenu because Bill said selecting Quit from the menu worked while a button with ‘quit’ didn’t.

But he reports that doesn’t work for him either, so perhaps doMenu doesn’t really 'do menu' under the hood.

If the Quit accelerator key combination also works (command-Q on Mac) then I’d next try:

      type ‘Q’ with commandKey

But I would not lock messages in any case.

Jim Lambert
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: DoMenu

Richard Gaskin
In reply to this post by Alain Farmer
Alain Farmer wrote:

 > Hello Richard,I disagree with your conclusion that DoMenu was
 > necessary in HyperCard because that language wasn't rich enough
 > to build an entire IDE in.

Did Apple ever release a version of HC with its IDE written in HyperTalk?


 > DoMenu was an integral part of HyperCard's ease-of learning-
 > to-program.One command (doMenu) versus many commands to learn/use
 > /remember.

I suppose it could be a matter of taste, whether one writes scripts that
invoke menu items that invoke commands or writes scripts that invoke the
commands directly.

Personally, "quit" seems simpler and more intuitive to me than "domenu
quit".

Reliance on doMenu as a language design element also introduces
inconsistencies:  what happens when you make your own custom menus and
still need access to a command normally handled by doMenu?

Even if HC allowed that, it would seem odd (at least to me) to have to
invoke a menu that doesn't exist.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: How to Quit with a button

Richard Gaskin
In reply to this post by Wprothero
William Prothero wrote:

 > I’ve tried a number of things to get my app to shut down without
 > crashing the app. I know it must be possible because the toolbar
 > menu quits fine. I may just stop trying to use a script to quit.
 > It’s not essential since the toolbar menu quits fine. Anyway, I’ve
 > tried locking messages, closing all substacks, delaying the “quit”
 > with a send command, and it crashes no matter.

When it crashes, does the OS present a dialog?  Anything in the system logs?

 > But, a bare stack works fine.

Interesting.  Any pending messages at the time quit is invoked?


--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: DoMenu

dunbarxx
In reply to this post by Richard Gaskin
Richard.


..."Reliance on doMenu as a language design element also introduces inconsistencies:  what happens when you make your own custom menus and still need access to a command normally handled by doMenu?"...


I understand the exigencies of cross platform support. That said, I miss most of all the menu handling in HC, as opposed to the button group in LC.


The creation of a custom menu with associated menuMessages was clean and clear, and those menuMessages could be invoked via "doMenu", but did not require it. The menuMessage handler references were loaded upon menu creation, accessible like ordinary handlers with a simple call.


But you know all this. I am obviously misunderstanding your statement above.


Craig



-----Original Message-----
From: Richard Gaskin <[hidden email]>
To: use-livecode <[hidden email]>
Sent: Mon, Dec 8, 2014 6:11 pm
Subject: Re: DoMenu


Alain Farmer wrote:

 > Hello Richard,I disagree with your conclusion that DoMenu was
 > necessary in HyperCard because that language wasn't rich enough
 > to build an entire IDE in.

Did Apple ever release a version of HC with its IDE written in HyperTalk?


 > DoMenu was an integral part of HyperCard's ease-of learning-
 > to-program.One command (doMenu) versus many commands to learn/use
 > /remember.

I suppose it could be a matter of taste, whether one writes scripts that
invoke menu items that invoke commands or writes scripts that invoke the
commands directly.

Personally, "quit" seems simpler and more intuitive to me than "domenu
quit".

Reliance on doMenu as a language design element also introduces
inconsistencies:  what happens when you make your own custom menus and
still need access to a command normally handled by doMenu?

Even if HC allowed that, it would seem odd (at least to me) to have to
invoke a menu that doesn't exist.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

 

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12