Fwd: Re: AW: IDE puzzler...
On 09/02/2016 12:54 PM, Paul Dupuis wrote: A inclusion option, where I could embed the script editor/debugger in my Standalone, so that I can debug bugs that surface in the standalone and mysteriously disappear in the IDE. I guess that would be sort of like replacing the errordialog with some sort of call to the debugger? Unfortunately, it's nowhere near that easy. Breakpoints and runtime errors are triggered in standalone applications, but they're ignored since there's nowhere to pass them to. PowerDebug does let you debug standalone applications if you include the library, because it handles communication between the standalone app and the debugger through socket calls and frontscript message wrappers. http://powerdebug.ahsoftware.net -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
AW: IDE puzzler...
Development > Suspend Development tools was probably the way to go. I was so busy looking for a "Preference" I missed seeing that in the Development menu In the mean time, since I already have a front-script that had a commandKeyDown message handler for other things, I just added a condition for the letter p to invoke my print command vs being passed to the IDE To one of Richmond's points - one I have no idea whether it is technically possible in the LiveCode architecture or not, but if it is - I'd really like an "Run As App mode where my desktop app behaved exactly like a Standalone but with access to the debugger/script editor OR A inclusion option, where I could embed the script editor/debugger in my Standalone, so that I can debug bugs that surface in the standalone and mysteriously disappear in the IDE. I guess that would be sort of like replacing the errordialog with some sort of call to the debugger? Anyway, thank you all. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IDE puzzler...
At 2:04 PM -0400 9/2/2016, Paul Dupuis wrote: But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? Develop > Suspend Development Tools should do it. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IDE puzzler...
What about "Suspend Development Tools"? The Whole IDE vanishes, and you are left with your work . . . . Richmond. On 2.09.2016 21:04, Paul Dupuis wrote: So I just wasted an hour tracking down a sort of "problem" that was not really a problem. My desktop app has printing and selecting "Print..." from the File menu of my app was doing the "right" think, but Comand/Control-P was not. Sadly, it took me a whole hour to realize that the Command-P was being passed to the IDE and invoking the IDE's File > Print Card... menu item, which looked enough like a very old version of our printing code in this case to make me think that tons of recent changes had someone "been undone". So, problem solved in once sense in that when the Standalone gets built, Command/Control-P will end up invoking my printer code, but the IDEs. But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? I could see nothing in Preferences. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IDE puzzler...
Hey look: http://www.theregister.co.uk/2007/02/27/revolution_runtime/ "One of the best features of" . . . Livecode . . . "is the ability to flip flop between edit mode and run mode." Um . . . tooth-sucking time. Richmond. On 2.09.2016 21:04, Paul Dupuis wrote: So I just wasted an hour tracking down a sort of "problem" that was not really a problem. My desktop app has printing and selecting "Print..." from the File menu of my app was doing the "right" think, but Comand/Control-P was not. Sadly, it took me a whole hour to realize that the Command-P was being passed to the IDE and invoking the IDE's File > Print Card... menu item, which looked enough like a very old version of our printing code in this case to make me think that tons of recent changes had someone "been undone". So, problem solved in once sense in that when the Standalone gets built, Command/Control-P will end up invoking my printer code, but the IDEs. But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? I could see nothing in Preferences. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IDE puzzler...
I feel a "Richmond naive remark" coming on: On 2.09.2016 21:04, Paul Dupuis wrote: So I just wasted an hour tracking down a sort of "problem" that was not really a problem. My desktop app has printing and selecting "Print..." from the File menu of my app was doing the "right" think, but Comand/Control-P was not. Sadly, it took me a whole hour to realize that the Command-P was being passed to the IDE and invoking the IDE's File > Print Card... menu item, which looked enough like a very old version of our printing code in this case to make me think that tons of recent changes had someone "been undone". So, problem solved in once sense in that when the Standalone gets built, Command/Control-P will end up invoking my printer code, but the IDEs. But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? But's that what I thought 'Browse' mode was for. Obviously I was wrong . . . So; here's an idea (probably almost as naive as that remark): How about an 'App' mode where one can get a feel for how the stack(s) will run when compiled as a standalone? At least as far as the OS the stacks is being developed on. I could see nothing in Preferences. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: IDE puzzler...
You can do this by handling the commandKey or controlKey message. Use a front script if necessary. Kind regards, Mark Schonewille http://economy-x-talk.com https://www.facebook.com/marksch Buy the most extensive book on the LiveCode language: http://livecodebeginner.economy-x-talk.com Op 02-Sep-16 om 20:04 schreef Paul Dupuis: So I just wasted an hour tracking down a sort of "problem" that was not really a problem. My desktop app has printing and selecting "Print..." from the File menu of my app was doing the "right" think, but Comand/Control-P was not. Sadly, it took me a whole hour to realize that the Command-P was being passed to the IDE and invoking the IDE's File > Print Card... menu item, which looked enough like a very old version of our printing code in this case to make me think that tons of recent changes had someone "been undone". So, problem solved in once sense in that when the Standalone gets built, Command/Control-P will end up invoking my printer code, but the IDEs. But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? I could see nothing in Preferences. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
IDE puzzler...
So I just wasted an hour tracking down a sort of "problem" that was not really a problem. My desktop app has printing and selecting "Print..." from the File menu of my app was doing the "right" think, but Comand/Control-P was not. Sadly, it took me a whole hour to realize that the Command-P was being passed to the IDE and invoking the IDE's File > Print Card... menu item, which looked enough like a very old version of our printing code in this case to make me think that tons of recent changes had someone "been undone". So, problem solved in once sense in that when the Standalone gets built, Command/Control-P will end up invoking my printer code, but the IDEs. But, here is the puzzler, is there a way to tell the IDE to NOT handle menu keyboard equivalents and send those keyboard commands to the Applications menu so that all the functions of the App's menu can really be tested in the IDE? I could see nothing in Preferences. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
