OpenFileRequester - how to handle Cancel kind of events?

Just starting out? Need help? Post your questions and find answers here.
ljgww
Posts: 26
Joined: Thu Mar 26, 2020 5:47 pm

OpenFileRequester - how to handle Cancel kind of events?

Post by ljgww »

Its all fine when using OpenFileRequester when it comes to the branch where user selects one or more files. The specified back function gets called and file info is passed on to NextSelectedFile().

But, user can also close file dialog or press cancel button to close file open dialog window.

Help/Documentation says:
Callback The callback to be called if the user has selected one or several file. It won't be called if the user canceled the requester. It has to use the following syntax:

Procedure Callback()
; Code here
EndProcedure

later....

Return value
None.

I am not sure on how to recognize and handle this (cancel) situation. Documentation says and tests i tried show that in such case callback is not triggered at all. Perhaps this dialog need 2 callbacks?!? or some other mechanism/way...
User avatar
Peter
Posts: 1086
Joined: Mon Feb 24, 2014 10:17 pm
Location: 127.0.0.1:9080
Contact:

Re: OpenFileRequester - how to handle Cancel kind of events?

Post by Peter »

to clear it up for me: You want to know when the Cancel button is pressed in the OpenFileRequester?

Why? I can't imagine a scenario that requires such functionality at the moment. Do you have an example for me?
ljgww
Posts: 26
Joined: Thu Mar 26, 2020 5:47 pm

Re: OpenFileRequester - how to handle Cancel kind of events?

Post by ljgww »

Peter wrote:to clear it up for me: You want to know when the Cancel button is pressed in the OpenFileRequester?

Why? I can't imagine a scenario that requires such functionality at the moment. Do you have an example for me?
Thank you for considering this, Peter.

Yes I would like to have a mechanism where cancellation event is recognized somehow.

It is not that important if user pressed cancel button or he just closed the file dialog window, the result is the same. All other 'call back' controls have error mechanism (except for handlers, but handlers would either handle event or not - and they can be chained by further callbacks)

Not imagining scenario is understandable - we usually focus on what we've seen before or intentions of how something 'shall' be used not the way how someone 'may use it'. This kind of dialog would be in a typical GUI application called perhaps as menu event (e.g. 'File, Open ...' menu item) handling loading of 'document' or not.

In my case this file dialog comes before application even starts (that is during preparation phase of the app - in other words there is no underlying app yet at the time of file dialog) and since whole execution flow goes thru chained callbacks (as that seems to be the only method available because many of involved functions there only support async way of doing things) hence handling is typically covering success and error branch (Promises?). The flow die in case user cancels selecting the file as there is no 'error' or 'cancel' branch for this one to be caught, only success path.

So in my case it is some kind of 'wizard' flow scenario that offshoots necessary controls and then, depending on what user decided on the way - the appropriate end GUI is rendered (or there is further actions/decisions to be taken)

If some of these calls have not been done in async way it could be possible to keep the control. I understand that this 'call back' flow is driven by underlying JavaScript execution engine. But, this also drives the application architecture style out of imperative waters. (and understandably There is no silver bullet. :) things are as they are)

In PureBasic this part is easier as it do not depend on callbacks (code taken from PureBasic help) for the same functionality.

Code: Select all

 
  File$ = OpenFileRequester("Please choose file to load", StandardFile$, Pattern$, Pattern)
  If File$
    MessageRequester("Information", "You have selected following file:" + Chr(10) + File$, 0)
  Else
    MessageRequester("Information", "The requester was canceled.", 0) 
  EndIf
Of course I do not expect that SpiderBasic would be or should be following PureBasic way of doing things (primarily due different nature of underlying executable engines).

PS skipped some but's :) You will catch my drift.
User avatar
Peter
Posts: 1086
Joined: Mon Feb 24, 2014 10:17 pm
Location: 127.0.0.1:9080
Contact:

Re: OpenFileRequester - how to handle Cancel kind of events?

Post by Peter »

i did some research and unfortunately couldn't find a way to query the cancel button. This is not primarily due to SpiderBasic but to the limitations of JavaScript.

Greetings ... Peter
ljgww
Posts: 26
Joined: Thu Mar 26, 2020 5:47 pm

Re: OpenFileRequester - how to handle Cancel kind of events?

Post by ljgww »

Peter wrote:i did some research and unfortunately couldn't find a way to query the cancel button. This is not primarily due to SpiderBasic but to the limitations of JavaScript.

Greetings ... Peter
I can understand this. No silver bullet. Thank you for spending time to look it up.

I did some of my pondering in the meantime.

Reasoning behind this is that open file dialog is a system call (all browsers call underlying OS to do this, things do not even happen in the browser). I know this from the browser automation: It is not possible to automate file open from within the browser (unless you get out to OS and automate process outside of browser). I argued that browser shall make open file an internal programmatic function and make it customizable - not a system call, but this is too detailed for general population (focus is elsewhere), and browser authors seem not being interested to change something in this area as this is working for last 25 years in the same way and everyone knows how to use it. That will not stop developers asking questions as this is conceptual problem.

On the other hand this call is triggered as event in only one possible way and that is by automating clicking on input file HTML tag. There is a lot of discussion about this for other purposes but it does not seem to be resolved in some reliable way.

One of ideas was to catch if value of file field remained empty after the fact, but again, there is no event to hang on to catch the situation. If it cannot be resolved on JS side it cannot be resolved in SB. That's it. Life goes on. We find other ways...

Hence, I concur with you. At the moment there is no solution for this (or I did not find it either :) ). At least until this becomes a browser issue.
Post Reply