On drop, first display alert, wait for a response, then do the rest.

Hi everyone

I have this drop handler and it checks the kind of files and then processes them it’s kinda like:

repeat with theFile in theFiles
if theFile = "app" then
	ProccessApp(theFile)
else
	ProcessElse(theFile)
end if
end repeat

on ProcessElse(theFile)
	display alert <....> attached to window "main"
end ProcessElse

on alert ended theObject with reply withReply
	--some stuff
end alert ended

This is of course not all the code I’m using but it can go as an example :). If the first item in theFiles is a file, it goes to ProcessElse and then it directly goes to ProcessApp and then to the alert. I want the alert to be done first and then the repeat loop doing the other files (going to ProcessApp in this case). I think this is probably asked before but I don’t know what to search for.

Any help would be greatly appreciated.

Why not just move the repeat loop into the “on alert ended” handler? In the on drop handler you could set theFiles to some global variable so that variable is available in the on alert ended handler to repeat through the files.

Because, in the above example <I know it isn’t in it>, only an alert gets displayed if the handler ProcessElse gets called, no alerts will be displayed in the ProccessApp. You suggest I use the same code twice in on drop & alert ended? Or do you have something else in mind?

I don’t think I clearly understand what you want then. But here’s one more suggestion. I you want to do 2 different things at 2 different times then create 2 different lists of files. One list is the processapp files and one is the processelse files. Then you can handle one first with the alert, and then when they’re finished process the other ones.

Thanks, great idea

Maybe this example makes it more clearly:

repeat with theFile in {"test.app", "test.jpg", "test2.jpg"}
	if theFile = "app" then --this doesn't work correctly in the example, I'm just saving space in code here.
		ProccessApp(theFile)
	else
		ProcessElse(theFile)
	end if
end repeat

on ProcessElse(theFile)
	display alert <....> attached to window "main"
end ProcessElse

on ProcessApp(theFile)
	 --do some stuff with theFile
end ProcessApp

on alert  theObject with reply withReply
	--this is the alert from ProcessElse
	--let the user choose what to do with the files
end alert ended

So first, it’s an app, it gets processed good, then it’s a file so the ProcessElse handler gets called and displays the alert. but then immediately it moves on to the next item in the list which is also a file but by then, the display alert gets ignored because there’s already an alert being displayed… So I can only do stuff with the first alert.

Instead of the display alert I could try for example, text returned of display dialog “test” default answer “”, in this case, the repeat loop waits for a reaction before moving on.

But as you said, creating 2 lists might work for me but then I have another problem, what if have a something like this:

on ProcessFiles()
	if FilesList contains --bunch of for example file types then
		repeat with i in FilteredFilesList --this is a filtered list
			display alert i attached to window "main"
		end repeat
	end if
end ProcessFiles

on alert ended with reply withreply
	--some code
end alert ended

This still screws things up, alternatively I could use:

on ProcessFiles()
	if FilesList contains --bunch of for example file types then
		display alert attached to window "main"
	end if
end ProcessFiles

on alert ended with reply withreply
	--some code
end alert ended

But this won’t display me an alert for every file, it will only display one. (it’s better than nothing though)

OK, now I understand. Basically there’s 2 kinds of dialogs, application modal and document modal. Document modal is when you attach the dialog to a window. In this case the code continues to execute and the response from the dialog is handled in the “alert ended” or “panel ended” handlers. With application modal the whole application pauses while the dialog is displayed. The code does not continue to execute while the dialog is open. The response from the dialog is handled right in your code and not in the aforementioned handlers.

So you want an application modal alert dialog. To get that just don’t attach the dialog to a window.

You can see an example of this in the example project “Display Alert” found in /Developer/Examples/Applescript Studio" folder. Run that and check/un-check “as sheet” to see the different behavior.

Yes, I know if I display it if it’s not attached it will work just fine. (don’t know anything about the modal stuff though) but I was hoping if I could have an attached application modal… I can’t change that anywhere or can I ? And what about ordinary panels/windows? Can I change the behavior when there still attached from document modal to application modal ?

Thanks for the explanation though :slight_smile:

Nope, there’s no such thing as an attached application modal dialog and there’s no changing between them… this is how Apple set it up. All alerts/dialogs work this way.

Hmm, I’ll guess I’ll have to use application modals then.
I could always use this but I have a feeling about it eating CPU,

repeat
	delay 1
	if continue then
		repeat with i in y
			--code
			set continue to false
			display alert
			--code
		end repeat
	end if
end repeat

on alert ended with reply withreply
	--code
end alert ended

Thanks for everything :slight_smile:

Sorry to get back to this but what about this?

Came from here and here

Some people try to use:

display window "sheet" attached to window "main"

To stop the code from going on…

But this gives me an error:

Can't get window "main". (-1728)

I have never used it because I always use panels…

display panel "sheet" attached to window "main"

But is it true if I use attached NSPanels that the code stops? Or is this all wrong information somehow?