How do I know if I won't receive a FileOpen event?
-
I have an application that edits files. When the user double clicks on a file, my application is launched and the
FileOpenevent is received. When my application is launched directly by the user, a dialog window for creating a new file is shown.The problem that I'm having is that I don't know if I'm not going to receive the
FileOpenevent. When my application launches, I show the file creation dialog window. Then when I receive theFileOpenevent, I close the dialog window and open the file. The result is that the dialog window flashes on the screen for a moment.FileOpenis received afterApplicationStateChangewhich means I can't wait untilApplicationStateChangeand then show the dialog only ifFileOpenwasn't received.Should I set a timer to show the dialog after 500ms if
FileOpenwasn't received? That seems kind of hacky to me. I don't really want to sacrifice launch time to get this to work. Is there another way of getting this information other than through events? -
I've just discovered some shocking news. The FileOpen event is only supported by macOS.
Seriously? Why? I'm genuinely shocked.
@Kerndog73 said in How do I know if I won't receive a FileOpen event?:
Why?
That you should ask Qt developers on their mailing list
-
@Kerndog73 said in How do I know if I won't receive a FileOpen event?:
Why?
That you should ask Qt developers on their mailing list
-
@Kerndog73 Well, I don't know why it is only supported on MacOS. You can take a look at the source code, maybe you will find out why.
-
My solution for the moment is to set a timer for 100ms. I consistently have about 20-30ms to spare so this seems to be a good time. The big problem with this is that I'm setting a timer for 100ms! This just feels so wrong. There has to be a better way.
This is just as bad as those ancient video games that depend on the clock speed of the machine they're running on.
-
My solution for the moment is to set a timer for 100ms. I consistently have about 20-30ms to spare so this seems to be a good time. The big problem with this is that I'm setting a timer for 100ms! This just feels so wrong. There has to be a better way.
This is just as bad as those ancient video games that depend on the clock speed of the machine they're running on.
@Kerndog73 I'm not sure, but don't you get the file name user double clicked, as a parameter to your app (I mean argc/argv)? If this is the case you don't need that event and can easily check whether you should show file open dialog or not.
-
@Kerndog73 I'm not sure, but don't you get the file name user double clicked, as a parameter to your app (I mean argc/argv)? If this is the case you don't need that event and can easily check whether you should show file open dialog or not.
-
Hi,
There's nothing specially shocking, it just means that there was no other OS providing a similar event as macOS does.
-
Hi,
There's nothing specially shocking, it just means that there was no other OS providing a similar event as macOS does.
-
I don't know how that part is currently done on Windows. It could be just that a parameter is passed to the executable or something completely different.
-
I don't know OS-X guts well enough to give a precise answer, but in the underlying Cocoa API's, it's possible to decide you aren't getting on initial openFile event as soon as you get the applicationDidFinishLaunching event. I dunno if that's actually plumbed through to Qt in any obvious way, or if it's easy to check by dropping to some native code in a way that doesn't break Qt.
Maybe it's enough to set a 0ms timer rather than 100ms? I don't have a Mac to test with, but perhaps the timeout of a 0ms timer won't actually be serviced until after the application has "finished launching" ?
-
I don't know OS-X guts well enough to give a precise answer, but in the underlying Cocoa API's, it's possible to decide you aren't getting on initial openFile event as soon as you get the applicationDidFinishLaunching event. I dunno if that's actually plumbed through to Qt in any obvious way, or if it's easy to check by dropping to some native code in a way that doesn't break Qt.
Maybe it's enough to set a 0ms timer rather than 100ms? I don't have a Mac to test with, but perhaps the timeout of a 0ms timer won't actually be serviced until after the application has "finished launching" ?
@wrosecrans A 0ms timer seems to have solved the problem! The timer only times out after the application is fully initialised. This kind of makes sense because a 0ms timer is the “right solution” to some other problems too.
