Save file dialogs...

[Paul Dupuis]

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.
>