Component drops through alwaysOnTop-window


#1

I have a window, that includes a component. The included component is loaded dynamically and compiled seperately, and it’s the only one that exhibits this weird problem:

When I make the owning window go allwaysOnTop, the included component vanishes from the window. If I move the window, the component appears behind it, stuck on the screen with no owning window.

The problem only arises on mac (both Intel and PPC).

Any help would be much appreciated! Thanks in advance…

-A


#2

Sounds very odd. You’re definitely not calling addToDesktop for it, then?


#3

I am not calling addToDesktop for anything - which of the window and the disappearing component is “it” in your post refering to?

-A


#4

(I meant the component that’s disappearing). There’s no other way it could get onto the desktop… I think you need to put some breakpoints in there and find more clues about what’s going on. Catch it in the HIViewComponentPeer constructor so you can see when it’s getting put on the desktop.


#5

The last posting confuses me. In my project, there is no such thing as a HIViewComponentPeer (not even a ComponentPeer) - and the Juce API says nothing about it either…?

If you remember my earlier post today, you may suggest I upgrade Juce to the new version from 1.21…?

-A


#6

Ah yes, you might want to upgrade. I don’t remember any bug like this, but the windowing code has all completely changed on the mac since then.


#7

Cool, that sounds great. The upgrade will be complete in a week or so, and then I will try it out - and report in with success or failure.

Thanks!

-A


#8

Okay, Juce is upgraded, but the problem remains. The advice about HIViewComponentPeer was excellent, here’s what I found:

In [ void Component::setAlwaysOnTop (const bool shouldStayOnTop) ] I end up in this code:

if (! peer->setAlwaysOnTop (shouldStayOnTop))
{
// some kinds of peer can’t change their always-on-top status, so
// for these, we’ll need to create a new window
const int oldFlags = peer->getStyleFlags();
removeFromDesktop();
addToDesktop (oldFlags);
[…]

Appearently, this “kind of peer” does not cause problems on PC. In general, what kinds of peers cause problems like this? What is the easiest way to convince the peer to be another “kind of peer” that won’t cause problems?

Another thing I noticed, is that pretty much ALL the time an HIViewComponentPeer is created, the variable ‘viewToAttachTo’ is NULL. Now, since my problem is that a subcomponent “falls through” the view it is supposed to (remain) attach(ed) to - maybe the error is that ‘viewToAttachTo’ is not the view I wish it to be? It should be obvious that I’m not at all sure what ‘view’ refers to, what a peer really is, or what is generally going on, so I hope there are some similar problems out there, or a hunch to go by…

Thanks in advance!

-A


#9

…you say you’re not adding the subcomponent to the desktop, but it can’t reach that code unless the compoent is on the desktop!

You’re not trying to embed some kind of ResizableWindow or something, are you? They’ll automatically go onto the desktop unless you tell them not to.


#10

I think the biggest problem is that I didn’t write this code myself -
anyway:

Some component is embedded in the main-window. This is the one dropping through. It inherits from Component, and includes a dynamically loaded component. I guess it is not a ResizeableWindow that automatically goes to desktop, because then it would for PC as well. If it is - how can I tell it not to?

I am not explicitly adding the component to the desktop, as far as I know. But “it can’t reach that code unless the compoent is on the desktop” hints that I have to check up on that, and maybe the error will be clear as sunshine. I’ll check. Thanks so far!

-A


#11

Being dynamically loaded is a bit scary - that could cause any number of strange situations. Can’t think of anything else to suggest, you’ll need to do some more investigation into what’s actually happening.


#12

I’m searching for the place where something gets added to desktop. Can this happen without calling addToDesktop()?

-A


#13

[quote=“amygdala”]I’m searching for the place where something gets added to desktop. Can this happen without calling addToDesktop()?

-A[/quote]

No.

Like I suggested several posts back, try a breakpoint in the ComponentPeer constructor.


#14

Some questions about the HIViewComponentPeer cTor:

  • What am I looking for?
  • Does it have any significance, that viewToAttachTo is zero?
  • Will my dynamically loaded component need it’s own HIViewCP? If so, all except my main window executes the HIViewCP-cTor with unnamed argument Component - and this component has no distinguishing features, so I can’t tell, whether it’s the err’ed component or not.
  • What’s wrong? (I’m kidding, but at the same time clueless…)

Thanks again, I appreciate your help immensly!

-A


#15

If the component isn’t a window on its own, then it shouldn’t have a peer at all. So you’re looking for whatever bit of code is incorrectly putting it on the desktop, by catching it when the peer is created.


#16