Sorry for replying late, it was lunch time.

quote:Original post by davidsporn

public void XXX(){  controler.deleteCurrentFile();  fileList.removeItem(fileList.getSelectedIndex());}  

quote:Original post by Advanced Bug
This is what I meant when I said: "depends in an obscure way on the order of operations". It is absolutely not obvious that you must remove the file BEFORE removing the correspoding listbox item.

On the contrary, it IS obvious that you must remove the file before removing the listbox item, because it is the listbox that manages the list of files.

quote:Original post by Advanced Bug
Sure it solves this concrete problem. But there''s no way to predict where similar problem will show up next time. In general, you should be ready to handle an unexpected callback at any point when you call some library function.

Usually when you use a library, callbacks are documented, so a callback is rarely "unexpected". And then, even if it is unexpected, you quickly learn about its existence.
Then, this is one of the purpose of the controler, from the controler developper point of view : to encapsulate each operation to ensure that nothing interfere with the processing in progress.
Beside this, by separating the data from the UI, you will get rid of UI related callback during data processing, i.e. most (if not all) of the callbacks. (this is the famous MVC pattern -Model-View-Controler).
Sure, there''s no way to predict where similar problem will show up next time. But a good design and a relevant and accurate set of requirements will help to avoid a bunch of them, and makes remaining problem less tricky to solve.


----
David Sporn AKA Sporniket

quote:Original post by Kylotan
Did this get mixed up somewhere, or was it just me?

I thought the problem was that you have to remove the entry before you do the deletion, otherwise the file gets recreated?

Personally, I''d say that it was intuitive to remove the file from the list before deleting it; this way there''s never a point where a list is referring to an invalid file. Remove all the references, and then kill the object.

gaahh, I see what you mean... yes it works too.



----
David Sporn AKA Sporniket

quote:Original post by Ready4Dis
I don''t get it... why not just store the LAST item that was selected, so when it selects the new item, you can just use the old item ID to do your deletion stuff? Wouldn''t that save you a hole bunch of problems?

He''s not asking you to solve the problem. He''s suggesting that nested callbacks cause problems.

quote:Original post by Kylotan
On a higher level, I can''t see a good solution to the general problem. If you placed some arbitrary restriction on callbacks, you''d have to take that into account in your code too. (eg. the OnChange handler doesn''t get called if we remove the current selection from code, so we have to manually call it everywhere.) So all you''d be doing is moving the problem from one place to another.

What if everything was done with a message queue?

quote:Original post by Kylotan
On a higher level, I can''t see a good solution to the general problem. If you placed some arbitrary restriction on callbacks, you''d have to take that into account in your code too. (eg. the OnChange handler doesn''t get called if we remove the current selection from code, so we have to manually call it everywhere.) So all you''d be doing is moving the problem from one place to another.

Not everywhere, just where you change it /and/ want it to run the change event handler. If you always wanted to call it or always didn''t want to call the problem would be simple. But sometimes you do want to call it, and sometimes you don''t. Swing et. al. always call it, MFC/ATL/WTL never do. And it''s easier to call something that''s not getting called, than to "uncall" something that is

quote:NotAnAnonymousPoster
What if everything was done with a message queue?

You regain control over the order of event invocation, but the events are still raised redundantly. This would be highly annoying, but at least it would work. Sometimes you need to do this with Win32/MFC. For example, you''re not allowed to change the contents of a tree-control while handling a select event on one. In a particular app, when the user double-clicked on a node, I wanted it to make that node the root of the tree. In order to do so, I had to make (and send) a custom message, so that I could change the tree control right after the double-click event.