Hi,
I did not look at the code but the behavior you describe is typical of the
concurrency triggered by the event handler. Each time an "update" call is
made or worse an "after", Tcl will look in pending events and start
processing them. So you open file1, process 10% of it, refresh the
progressbar by an "update" and to check wether the user pressed "cancel" :
the event loop will start processing file2. Maybe internal Scid code thinks
the base slot used by file1 is still free and try to open file2 on the same
slot, for example.
One solution maybe to only use "update idletasks" so no new events are
(except UI refresh) processed, or write a procedure that will open one file
only after the previous one is finished.
So the idea is the following : If multiple files are dropped, "proc
dragndrop {file}" must be called only once with a list of files as
arguments. As long as this proc is running, no other drag and drop should be
allowed. If in current implementation dropping 3 files at once triggers 3
times the proc, then there is some trouble (non reentrant code).
Pascal
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
