Re: Save file dialogs...
http://quality.livecode.com/show_bug.cgi?id=20600 Requested as an enhancement to the 'ask file' engine command. The next question might be what form would that enhancement take? If we look at the syntax of: ask file prompt [with defaultFilePath] [with type types [or type types ...]] [as sheet] You could consider a enhancement where: ask file prompt [with defaultFilePath] [with type types [or type types ...]] [with callback callbackMessage] [as sheet] If the callbackMessage is present the dialog remains, even when the cancel or save button are pressed and instead the callBackMessage is sent to the object that invoked the ask file dialog with the value of the action the user performed as a parameter, i.e. on callBackMessage pAction switch pAction case "Cancel" close window "Ask File" break case "Save" close window "Ask File -- perform save action break case "Plain Text" -- the value of the type popup that was just changed, normally what is returned in 'the result' -- update the default file name in the 'ask file' dialog, but how best to implement this? A property of the window? set the defaultFilepath of window 'Ask File" to pCurrentFileName & tNewExtension break case "MS Word" -- similar to "Plain Text" break end switch end callBackMessage On 10/23/2017 10:02 PM, Richard Gaskin via use-livecode wrote: > Paul Dupuis wrote: > > > On 10/23/2017 4:23 PM, Richard Gaskin via use-livecode wrote: > >> Trevor DeVore wrote: > >> > >> > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode < > >> > use-livecode at lists.runrev.com> wrote: > >> > > >> >> One option would be to leave the extension off when initially > >> >> presented to the user. Then add the correct extension before > >> >> saving if the user did not manually add one. It is probably a > >> >> little more complicated than that though... unless the user has > >> >> their OS set to display extensions, they may not be presented > >> >> with them normally. I’m not sure if that is detectable from > >> >> within LC though. > >> > > >> > One thing to be aware of with this approach is that it won’t work > >> > if your app is sandboxed (apps distributed through the Mac App > >> > Store are sandboxed). When sandboxed you can only write to a file > >> > path that the user explicitly specifies. You will get an error if > >> > you try to change the path that the user specified in the save as > >> > dialog. > >> > >> Good point. Thanks for that, Trevor. > >> > >> It would seem an enhancement request is in order. > >> > >> Paul, are you in a position to file that? > > > > I will file an enhancement request. I'd like to see a > > future/alternative version of ask file that provides the callbacks > > Ralph mentioned. Perhaps as an LCB widget? > > Thanks in advance. It'll be good to get that standard behavior. > > If it were a new command/function, writing it with LCB using FFI would > probably be an excellent choice. Indeed, just about anyone in the > community could do it. > > But in this case it's an extension of an existing command built into > the engine, so doing this feature completion in the existing engine > code would seem maybe a better move. > > After all, if it were written in LCB, we'd then have two different > versions of some form of Ask File command, and we'd have to remember > the nuances between them, which one has what, and if we want the LCB > version we'd have to remember to add that component wherever it's needed. > > As a feature completion of the existing engine-based command, this > would be available to everyone always, and it's common enough to > expect most folks will want it. And less to remember. > ___ 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: Save file dialogs...
Paul Dupuis wrote: > On 10/23/2017 4:23 PM, Richard Gaskin via use-livecode wrote: >> Trevor DeVore wrote: >> >> > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode < >> > use-livecode at lists.runrev.com> wrote: >> > >> >> One option would be to leave the extension off when initially >> >> presented to the user. Then add the correct extension before >> >> saving if the user did not manually add one. It is probably a >> >> little more complicated than that though... unless the user has >> >> their OS set to display extensions, they may not be presented >> >> with them normally. I’m not sure if that is detectable from >> >> within LC though. >> > >> > One thing to be aware of with this approach is that it won’t work >> > if your app is sandboxed (apps distributed through the Mac App >> > Store are sandboxed). When sandboxed you can only write to a file >> > path that the user explicitly specifies. You will get an error if >> > you try to change the path that the user specified in the save as >> > dialog. >> >> Good point. Thanks for that, Trevor. >> >> It would seem an enhancement request is in order. >> >> Paul, are you in a position to file that? > > I will file an enhancement request. I'd like to see a > future/alternative version of ask file that provides the callbacks > Ralph mentioned. Perhaps as an LCB widget? Thanks in advance. It'll be good to get that standard behavior. If it were a new command/function, writing it with LCB using FFI would probably be an excellent choice. Indeed, just about anyone in the community could do it. But in this case it's an extension of an existing command built into the engine, so doing this feature completion in the existing engine code would seem maybe a better move. After all, if it were written in LCB, we'd then have two different versions of some form of Ask File command, and we'd have to remember the nuances between them, which one has what, and if we want the LCB version we'd have to remember to add that component wherever it's needed. As a feature completion of the existing engine-based command, this would be available to everyone always, and it's common enough to expect most folks will want it. And less to remember. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Save file dialogs...
On 10/23/2017 4:23 PM, Richard Gaskin via use-livecode wrote: > Trevor DeVore wrote: > > > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode < > > use-livecode at lists.runrev.com> wrote: > > > >> One option would be to leave the extension off when initially > >> presented to the user. Then add the correct extension before saving > >> if the user did not manually add one. It is probably a little more > >> complicated than that though... unless the user has their OS set to > >> display extensions, they may not be presented with them normally. I’m > >> not sure if that is detectable from within LC though. > > > > One thing to be aware of with this approach is that it won’t work if > > your app is sandboxed (apps distributed through the Mac App Store are > > sandboxed). When sandboxed you can only write to a file path that the > > user explicitly specifies. You will get an error if you try to change > > the path that the user specified in the save as dialog. > > Good point. Thanks for that, Trevor. > > It would seem an enhancement request is in order. > > Paul, are you in a position to file that? > I will file an enhancement request. I'd like to see a future/alternative version of ask file that provides the callbacks Ralph mentioned. Perhaps as an LCB widget? ___ 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: Save file dialogs...
Trevor DeVore wrote: > On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode < > use-livecode at lists.runrev.com> wrote: > >> One option would be to leave the extension off when initially >> presented to the user. Then add the correct extension before saving >> if the user did not manually add one. It is probably a little more >> complicated than that though... unless the user has their OS set to >> display extensions, they may not be presented with them normally. I’m >> not sure if that is detectable from within LC though. > > One thing to be aware of with this approach is that it won’t work if > your app is sandboxed (apps distributed through the Mac App Store are > sandboxed). When sandboxed you can only write to a file path that the > user explicitly specifies. You will get an error if you try to change > the path that the user specified in the save as dialog. Good point. Thanks for that, Trevor. It would seem an enhancement request is in order. Paul, are you in a position to file that? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Save file dialogs...
On Mon, Oct 23, 2017 at 11:32 AM Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > One option would be to leave the extension off when initially presented to > the user. Then add the correct extension before saving if the user did not > manually add one. It is probably a little more complicated than that > though... unless the user has their OS set to display extensions, they may > not be presented with them normally. I’m not sure if that is detectable > from within LC though. One thing to be aware of with this approach is that it won’t work if your app is sandboxed (apps distributed through the Mac App Store are sandboxed). When sandboxed you can only write to a file path that the user explicitly specifies. You will get an error if you try to change the path that the user specified in the save as dialog. Trevor DeVore ScreenSteps > ___ 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: Save file dialogs...
In Windows you can add a hook into the open/save file dialogs. You get call backs for various events including changing the file type. I don’t know about Mac/Linux but I would assume the same(but different) facilities exist. Accessing the windows hooks would of course require changes to the engine. In Windows you can also get a callback when the user clicks the save/open/cancel before the dialog is closed. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Brian Milby via use-livecode Sent: Monday, October 23, 2017 12:32 PM To: How to use LiveCode Cc: Brian Milby Subject: Re: Save file dialogs... One option would be to leave the extension off when initially presented to the user. Then add the correct extension before saving if the user did not manually add one. It is probably a little more complicated than that though... unless the user has their OS set to display extensions, they may not be presented with them normally. I’m not sure if that is detectable from within LC though. At least on Mac this would require a change in the engine source to have extensions change in the dialog. On Mon, Oct 23, 2017 at 9:54 AM Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> wrote: > In our application we often provide our customers with the ability to > save information in a variety of formats using a code snippet such as: > > put "YourData.txt" into tDefaultFileName > put "Save some data as:" into tPrompt > put the defaultFolder & tDefaultFileName into tDefaultFilePath > put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" > into tTypes > ask file tPrompt with tDefaultFilePath with type tTypes > put it & cr & the result into fld 1 > > Note that "it" contains the file path and "the result" contains the > type selected (Plain Text, Word, RTF, whatever) > > It has been pointed out that most other application, on either OSX or > Windows, in a save file dialog, dynamically change the file extension > when a different type is selected from the save file popup menu. For > example, in the above code, if the use is initially presented with > "YourData.txt" and "Plain Text" as the type. If the user selected > "Microsoft Word" the extension presented in the dialog is not changed > to .docx dynamically. This does happen in most other commercial > applications (i.e. MS Word). > > You do get back the chosen type in the result, but only after the > dialog has been closed. You can use this to change the extension after > the fact, but apparently not dynamically. > > This behavior exists in at least 6.7.11 through 8.1.6 under both OSX > and Windows > > Questions for the community AND/OR the LiveCode mothership: > > 1) Is this a "bug"? > > 2) Is there any work around (like a secret callback message) to detect > when the popup type menu has been changed to dynamically update the > presented file name's extension? > > 3) Has anyone else in the community run into this and cares about it > or are my customers just being way to picky? > > > ___ > 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 ___ 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: Save file dialogs...
One option would be to leave the extension off when initially presented to the user. Then add the correct extension before saving if the user did not manually add one. It is probably a little more complicated than that though... unless the user has their OS set to display extensions, they may not be presented with them normally. I’m not sure if that is detectable from within LC though. At least on Mac this would require a change in the engine source to have extensions change in the dialog. On Mon, Oct 23, 2017 at 9:54 AM Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> wrote: > In our application we often provide our customers with the ability to > save information in a variety of formats using a code snippet such as: > > put "YourData.txt" into tDefaultFileName > put "Save some data as:" into tPrompt > put the defaultFolder & tDefaultFileName into tDefaultFilePath > put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" into > tTypes > ask file tPrompt with tDefaultFilePath with type tTypes > put it & cr & the result into fld 1 > > Note that "it" contains the file path and "the result" contains the type > selected (Plain Text, Word, RTF, whatever) > > It has been pointed out that most other application, on either OSX or > Windows, in a save file dialog, dynamically change the file extension > when a different type is selected from the save file popup menu. For > example, in the above code, if the use is initially presented with > "YourData.txt" and "Plain Text" as the type. If the user selected > "Microsoft Word" the extension presented in the dialog is not changed to > .docx dynamically. This does happen in most other commercial > applications (i.e. MS Word). > > You do get back the chosen type in the result, but only after the dialog > has been closed. You can use this to change the extension after the > fact, but apparently not dynamically. > > This behavior exists in at least 6.7.11 through 8.1.6 under both OSX and > Windows > > Questions for the community AND/OR the LiveCode mothership: > > 1) Is this a "bug"? > > 2) Is there any work around (like a secret callback message) to detect > when the popup type menu has been changed to dynamically update the > presented file name's extension? > > 3) Has anyone else in the community run into this and cares about it or > are my customers just being way to picky? > > > ___ > 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
Save file dialogs...
In our application we often provide our customers with the ability to save information in a variety of formats using a code snippet such as: put "YourData.txt" into tDefaultFileName put "Save some data as:" into tPrompt put the defaultFolder & tDefaultFileName into tDefaultFilePath put "Plain Text|txt"&"Rich Text|rtf"&"Microsoft Word|docx" into tTypes ask file tPrompt with tDefaultFilePath with type tTypes put it & cr & the result into fld 1 Note that "it" contains the file path and "the result" contains the type selected (Plain Text, Word, RTF, whatever) It has been pointed out that most other application, on either OSX or Windows, in a save file dialog, dynamically change the file extension when a different type is selected from the save file popup menu. For example, in the above code, if the use is initially presented with "YourData.txt" and "Plain Text" as the type. If the user selected "Microsoft Word" the extension presented in the dialog is not changed to .docx dynamically. This does happen in most other commercial applications (i.e. MS Word). You do get back the chosen type in the result, but only after the dialog has been closed. You can use this to change the extension after the fact, but apparently not dynamically. This behavior exists in at least 6.7.11 through 8.1.6 under both OSX and Windows Questions for the community AND/OR the LiveCode mothership: 1) Is this a "bug"? 2) Is there any work around (like a secret callback message) to detect when the popup type menu has been changed to dynamically update the presented file name's extension? 3) Has anyone else in the community run into this and cares about it or are my customers just being way to picky? ___ 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
