2 strange problems

I’ve got 2 really strange problems that I can’t seem to solve:

1st problem:

Since a while ago, when I compile my application in Debug, it won’t get the focus anymore. Strangely controls seem to respond, but keyboard doesn’t work. When I click some button that launches a PopupMenu, the PopupMenu disappears directly again after appearing, not letting me any time to choose an item.

When a modal window is opened, I can’t click the exit button of the modal window.

The application uses a native title bar, and that one is greyed, like the app doesn’t have the focus. In Release, everything works alright!

What could this be?

2nd problem:

In my Treeview, when some item is clicked, this launches a Thread. Before launching it, it is stopped with stopThread(-1) because it could have been launched before if the user clicked another TreeViewItem.
In Debug mode, the stopThread() seems to happen very shortly after the mouseclick on the TreeViewItem, whereas in Release mode, it can take up to 2 seconds, which is a big delay. How is this possible? What can I do about it?

I’m mystified by your focus problem - I’ll keep an eye open for it, but can’t think of any suggestions right now…

The other thing just sounds like something is blocking in the thread - you need to somehow figure out what it’s doing during that 2 seconds. Again, I can’t think of anything that might be causing it…

I totally forgot to mention that I am not using the tip! So this is the old Carbon code!

Ah, well good luck with that!

Found out what caused problem 2, but maybe YOU can explain why this problem actually occurs.

A while ago I posted my concern about DirectoryIterator, which can take an eternity to come back out of the constructor.
So to avoid this, I added the following line into DirectoryIterator’s while loop in the constructor (I don’t like modifying JUCE at all, but I had no choice):

But this doesn’t work in Release! Although it does in Debug. Strange isn’t it?

What I do now is to pass a Thread* thread pointer to the constructor, and just do the following:

And that actually works! But why doesn’t the other way work?

There’s a lock inside getCurrentThread, though haven’t a clue why it’d be different in debug mode! Maybe just a timing issue?

I don’t know, but now it at least works… It would be cool if you could a Thread *thread=0 as last parameter to the DirectoryIterator or maybe modify it so there’s no blocking in the constructor anymore.

We already discussed the thing about making the DirectoryIterator thread-aware, didn’t we? And I remember not liking the idea…

Right, won’t say anything anymore. [Maybe at least give the users the possibility to write their own DirectoryIterator without modifying the JUCE code? At the moment this is not possible because DirectoryIterator uses juce_XXX() functions which cannot be accessed from outside JUCE.]

Ok, good request.

(You actually can use those functions if you want to, you’d just need to declare them in the juce namespace)