This problem can't be solved.
You mix window with app. Just because you open 2 windows you don't have 2 apps.
Due to that, the code can't and won't jump between codeblocks.
What you do is:
Notify 1A
Notify 1B
So far no problem.
But by breaking the requester handling with your second window (you call a requester while one is active, you should have a global state that prevents that to happen), you enter a new call stack in between Notify 1A and 1B which results in:
Notify 1A
<-- Notify 2A, Notify 2B
Notify 1B
This means as long as Notify 2B hasn't been closed, the old part can't go on.
There are 2 simple ways around that problem with default requesters:
- Call requesters only in a linear way instead of trying to call it parallel (at least until we have multithreading if we ever have it)
- Use a state variable that is set if a requester is active and disable all other "requester start functionality" until the running requester has been finished. Thats after all the way modal / pseudo modal stuff is meant.
The only way to solve your way keeping that type of code structuring is to create your own not-requesters through BM windows you open that fake the behavior and add event hooks to react to it.
Default requesters will never work differently as you mainly try to use them wrong. Requesters, as their name already implies, request an action from a user. Going on without waiting for that action is quite pointless and undesired.
Think about it and the result of your "idea" with a simple confirm requester: What shall your following code do, if you don't know if the user will click on "ok" or "cancel"? The following if that takes care of the further processing will totally break.
FileRequester would be an even worse example of what happens when the code would go on before the requester returned.
You mix window with app. Just because you open 2 windows you don't have 2 apps.
Due to that, the code can't and won't jump between codeblocks.
What you do is:
Notify 1A
Notify 1B
So far no problem.
But by breaking the requester handling with your second window (you call a requester while one is active, you should have a global state that prevents that to happen), you enter a new call stack in between Notify 1A and 1B which results in:
Notify 1A
<-- Notify 2A, Notify 2B
Notify 1B
This means as long as Notify 2B hasn't been closed, the old part can't go on.
There are 2 simple ways around that problem with default requesters:
- Call requesters only in a linear way instead of trying to call it parallel (at least until we have multithreading if we ever have it)
- Use a state variable that is set if a requester is active and disable all other "requester start functionality" until the running requester has been finished. Thats after all the way modal / pseudo modal stuff is meant.
The only way to solve your way keeping that type of code structuring is to create your own not-requesters through BM windows you open that fake the behavior and add event hooks to react to it.
Default requesters will never work differently as you mainly try to use them wrong. Requesters, as their name already implies, request an action from a user. Going on without waiting for that action is quite pointless and undesired.
Think about it and the result of your "idea" with a simple confirm requester: What shall your following code do, if you don't know if the user will click on "ok" or "cancel"? The following if that takes care of the further processing will totally break.
FileRequester would be an even worse example of what happens when the code would go on before the requester returned.