Re: Front and Back Scripts on Mobile

@Richard: Thanks… confirmed… today it is working, yesterday it was not… go figure. create scroller and scrollerdidscroll now in our backscript. awesome! "Instead, a backscript scans controls during preOpenCard and anything that needs a scroller gets one instantiated for it (along the way it

Re: Applying scripts that don't compile

> The script editor save handling probably needs some sorting out as at the > moment it will appear to save but the erroring script won’t be applied. I’m > looking into that now. I think in the event the script application couldn’t > happen it should beep at you or something rather than save.

Re: Applying scripts that don't compile

> On 3 Jul 2016, at 10:12 AM, Mark Wieder wrote: > > Hmmm. > I guess I've gotten so used to the way glx2 works, where saving a stack and > applying/compiling a script are separate actions, that I didn't realize the > IDE's script editor conflated the two. That seems

Re: Applying scripts that don't compile

On 07/02/2016 01:07 PM, Mark Waddingham wrote: On 2016-07-02 21:48, J. Landman Gay wrote: It is possible to save the stack with the script editor frontmost, and the uncompiled script will be set and saved as-is. I've done that by accident and, as you say, all the handlers disappeared from the

Re: Applying scripts that don't compile

On 2016-07-02 21:48, J. Landman Gay wrote: It is possible to save the stack with the script editor frontmost, and the uncompiled script will be set and saved as-is. I've done that by accident and, as you say, all the handlers disappeared from the handler list, meaning it was set during the save.

Re: Applying scripts that don't compile

On 7/2/2016 1:49 PM, Mark Wieder wrote: On 07/02/2016 09:56 AM, J. Landman Gay wrote: I don't much care either since any change won't affect how I work, though I do tend slightly towards Monte's suggestion. But I can think of a reason why some might prefer to set a script that won't compile.

Re: Applying scripts that don't compile

On 2016-07-02 21:04, Richard Gaskin wrote: We can't use widgets as part of our custom drawing apps that use the pointer tool? Heh - I perhaps should have been much more specific there. The tool used to interact with an object (its effective tool) is a function of the cantSelect property of

Re: Applying scripts that don't compile

Mark Waddingham wrote: > Indeed, 'widgets' do actually have this distinction - they only > 'run' in Browser mode, when in 'pointer' mode notionally they > are considered to be being edited and thus processes that occur > whilst 'running' do not occur). We can't use widgets as part of our custom

Re: Applying scripts that don't compile

On 2016-07-02 17:52, Richard Gaskin wrote: If someone out there wants to set scripts that won't run it's not my place to tell them not to, but if it helps your development work to let that oddity go it won't affect anything I do since I prefer writing scripts that are at least possible to run.

Re: Applying scripts that don't compile

On 07/02/2016 09:56 AM, J. Landman Gay wrote: I don't much care either since any change won't affect how I work, though I do tend slightly towards Monte's suggestion. But I can think of a reason why some might prefer to set a script that won't compile. If you've been writing a very long script

Re: Front and Back Scripts on Mobile

Sannyasin Brahmanathaswami wrote: > Ralph wrote: >> I had this problem way back. Mark noted that that the scroller >> messages are sent to the stack that created the scroller. > > Does it makes sense to file this as an enhancement request? I believe a more accurate description is that the

Re: How to find the name of the recent card?

On 07/02/2016 09:40 AM, David Bovill wrote: Yes this is the best solution I think. I still miss not having the information at engine level to cover cases in which you may arrive form a number of stacks - and you don't not want to use a library, nor have to worry about inadvertent blocking of

Re: Applying scripts that don't compile

> Under what circumstances would someone > prefer to set a script that can't be executed? The 'not-compiling' could be a severe bug. -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Applying-scripts-that-don-t-compile-tp4706289p4706321.html Sent from the

Re: SVG Icon Inclusion Causes iOS app to crash

Bug report filed: http://quality.livecode.com/show_bug.cgi?id=17945 Subject: SVG Icon Inclusion Causes iOS app to crash 8.1.0 DP2 I had a lot of SVG icons on several stacks that are built into an iOS app. I had forgotten to set that as an inclusion and when I built for iOS, they were blank.

Re: Front and Back Scripts on Mobile

Ralph wrote: I had this problem way back. Mark noted that that the scroller messages are sent to the stack that created the scroller. Does it makes sense to file this as an enhancement request? All modern CMV systems provide for a controller to push a single model across many views. And

Re: Applying scripts that don't compile

On July 2, 2016 10:54:44 AM Richard Gaskin wrote: Under what circumstances would someone prefer to set a script that can't be executed? However you handle this is fine by me; I'd say do whatever's easiest for you. I don't much care either since any change won't

Re: How to find the name of the recent card?

Yes this is the best solution I think. I still miss not having the information at engine level to cover cases in which you may arrive form a number of stacks - and you don't not want to use a library, nor have to worry about inadvertent blocking of closecard messages. On 2 July 2016 at 17:33,

Re: How to find the name of the recent card?

Closecard works pretty well for the "store the card just exited" workaround. ## stack script local sLastCard on closecard put the id of the target into sLastCard end closecard function getLastCd return sLastCard end getLastCd on preopencard put getLastCd() -- grabs the value stored

Re: How to find the name of the recent card?

On 07/02/2016 08:41 AM, David Bovill wrote: Within the preOpenStack handler we haven't yet arrived - so the recent card should be as it is the recent card before actual going anywhere. But then the currentcard should not be already updated to return the value of the card you have not actually

Re: Applying scripts that don't compile

Monte Goulding wrote: > I’ve just submitted a patch for review that will mean that if the > global gREVDevelopment is true then a script that doesn’t compile > won’t actually be set on the object. That's not normal behavior? Under what circumstances would someone prefer to set a script that

Re: How to find the name of the recent card?

Yes true - I had second thoughts after posting. I think I also agree with Monte though :) Within the preOpenStack handler we haven't yet arrived - so the recent card should be as it is the recent card before actual going anywhere. But then the currentcard should not be already updated to return

Re: How to find the name of the recent card?

On 7/2/2016 11:09 AM, Mark Wieder wrote: > On 07/02/2016 07:20 AM, David Bovill wrote: >> It is inconsistent. > > Unsurprisingly, I find myself agreeing with Mark Waddingham here (we > Mark Ws have to stick together). In preOpenCard you're still in > transit, so you haven't yet arrived at the

Re: How to find the name of the recent card?

On 07/02/2016 07:20 AM, David Bovill wrote: It is inconsistent. Unsurprisingly, I find myself agreeing with Mark Waddingham here (we Mark Ws have to stick together). In preOpenCard you're still in transit, so you haven't yet arrived at the destination card. In that case the card you came

Re: Controls on mobile apps - am I missing something?

On 2016-07-01 12:33, Ben Rubinstein wrote: That's why I think "it would be better if" the existing basic controls worked reasonably well on mobile platforms, and the existence of the various libraries, widgets, and mobileControlxxx functions - while all of them being extremely valuable - does

Re: How to find the name of the recent card?

It is inconsistent. If the recent card is updated after preOpenCard - then the current card should behave the same. At the moment the recent cad and the current card return the same result in a preOpenCard handler. My use case is to create a quick handler which takes action depending on where

Re: Controls on mobile apps - am I missing something?

On 2016-07-01 11:49, Terence Heaford wrote: I think I understand, a native field for iOS (plus other mobile platforms) is a stretch goal. Well, actually, the 'stretch goal' (like all of stretches for Infinite LiveCode) are fully documented examples how to 'do that kind of thing' with

Re: Controls on mobile apps - am I missing something?

On 2016-07-01 21:03, Terence Heaford wrote: The button and popup button/menu. To me the text seems a little low within the display. Please report any minor display discrepancies you see in the quality center with pictures for comparison and OS details. Fraser has done a lot of work to

Re: How to find the name of the recent card?

On 2016-07-02 13:41, David Bovill wrote: Agreed - its' the inconsistency that is problematic. Also the inability to establish where you have come from before rendering the contents of the display is a fundamental hole in the language - as we simply have no access to the recent card here.

a note from a friend

Hello, I wanted to tell you something but please make sure that no one finds aout about this. Please read the note here Thx, s...@ezpzapps.com ___ use-livecode mailing list

Re: the detailed folders returning incorrect data

On 2016-07-01 17:14, Paul Dupuis wrote: The problem I am working on has to do with reading and writing a preferences file and a license file across platforms and within platforms across versions of the OS and even within a platform (Windows) and OS version, the wide range or ways corporate and

Re: How to find the name of the recent card?

Agreed - its' the inconsistency that is problematic. Also the inability to establish where you have come from before rendering the contents of the display is a fundamental hole in the language - as we simply have no access to the recent card here. Whether we get this by referring to the current

Re: the detailed folders returning incorrect data

On 7/1/2016 10:23 PM, Mark Wieder wrote: > Agreed. Please file a bug report on this. Already done. 5 messages above in the thread: http://quality.livecode.com/show_bug.cgi?id=17927 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit

Re: Front and Back Scripts on Mobile

I had this problem way back.  Mark noted that that the scroller messages are sent to the stack that created the scroller.   Ralph DiMola IT Director Evergreen Information Services Original message From: Sannyasin Brahmanathaswami Date:07/02/2016 00:42

Re: How to find the name of the recent card?

Looking at your report I'm not really sure if the bug is in the recent card or the current card. If preOpenCard is before the card is open then there's a good argument that it's the latter... Of course either may be an anomaly that may be difficult to do anything about. Cheers Monte Sent

Re: the detailed folders returning incorrect data

As Paul Dupuis pointed out, SpecialFolderPath() also accepts numbers. These are for Win32... specialFolderPath (2) : Programs specialFolderPath (5) : Documents specialFolderPath (6) : Favorites specialFolderPath (7) : startup specialFolderPath (8) : Recent specialFolderPath (9) : SendTo

How to find the name of the recent card?

In a preOpenCard handler I cannot find the name of the recent card - the card that you "came from". As far as i can tell this is a very basic bug that goes back to at least version 7. Does anyone have a work around The only thing i can think of is to do my own logging in an openCard or closeCard