Plugin window behaviour

[atom]

I get weird stuff in my plugins

• i use a MenuBarComponent and a global ApplicationManager, all menus are greyed-out most of the time, i need to click many times in weird places (can’t really tell witch place makes it work)
• when i click on a menu option it opens and closed the menu instantly, can’t select any option, i need to click somewhere where there is no option and then click on the menu again (some focus issues i guess)
• on the mac when i open a ModalDialog it’s always behhind the plugin window and i can’t bring it to front no matter what

[jules]

The menu will be greyed out if your window isn’t focused - maybe you just need to make it focusable?

If the host has made the plugin window always-on-top, then you’ll need to setAlwaysOnTop in your dialogs too…

And try the latest git code, I did some menu changes this week, that might make a difference.

[atom]

allrighty will pull the git code at night when my mind starts working and will rebuild everything from scratch.

[atom]

Well i have a crash with the new code, in standalone mode the deleteFilter() method crashes on exit

setContentComponent (0, true);

ResizableWindow method crashes when doing this assign:

contentComponent = newContentComponent;

it’s the ScopedPointer crash here:

ScopedPointer& operator= (ObjectType* const newObjectToTakePossessionOf)
	{
		if (object != newObjectToTakePossessionOf)
		{
			ObjectType* const oldObject = object;
			object = newObjectToTakePossessionOf;
			delete oldObject <---- crash;
		}

		return *this;
	}

it worked for a very very long time

[jules]

I can’t see any obvious bugs. It sounds like you’re deleting the editor component yourself, so that the resizablewindow is left with a dangling pointer…? Could be that in the older code, the resizablewindow checked the pointer before deleting it, and you managed to get away with it, whereas now it’s less forgiving.

[atom]

it’s weird, it’s not any of my plugin code, actually the thing that fails is the deletion of a TableListBox that i added to one of my components, if i comment out the deleteAndZero (myTableListBox) that Jucer created, there is no crash but there is a memory leak for that TableListBox component, don’t really know what to do, deleting it crashes not deleting it leaks memory.

[jules]

That sounds like a red herring to me - more likely that if you don’t delete the listbox then you happen to not see the crash just because of the way the heap is laid out. You need to put a breakpoint in your content component’s destructor and see where it’s getting deleted. It should be deleted by the scopedpointer, but my guess is that something else is getting there first.

[atom]

as always i’m using the latest tip…

the menubar focus/all options greyed out/flicker issue is still there, i used the plugin host and it’s there, the menu bar is very hard to operate, clicking on an option does not always show the menu, once used the menu get;s greyed out and it’s near to impossible to turn those options back on no matter what i click on the plugin window to gain focus, it’s all very weird.

[atom]

I just wanted to follow up on this. I click on the window, open the menu and the options are active, but once i move to some other menu (left/right) the menu greys everything out. So the focus is momentary only when i open the menu and then lost, even though the options are normal (not greyed out) on the first enter i can’t trigger any of them.

[jules]

Perhaps you just need to use setWantsKeyboardFocus (true) on your plugin component? It just sounds like the main comp doesn’t want focus, and you’re having to click on child comps that do want focus in order for it to work…

[atom]

it does not work for VST
standalone seems to work with or without that
the same thing happens to the old JUCER, the menu acts extremly weird, not loosing focus when editing components (the menu stays selected), and other stuff, so this is not my code related.

[jules]

The menus seem fine to me… What would I have to do to get the jucer or juce demo to do this?

[atom]

http://www.screentoaster.com/watch/stUElWQENJRFtYSVpZWVxfUV9X/jucer_not_working
http://www.screentoaster.com/watch/stUElWQENJRFtYSVpZWVJcU15Q/plugin_wrapper_menu_bar

here are two videos that demonstrate this, theese apps are pure builds of your code nothing modified, i use Win7 x32 and VCExpress.

also i have JucePlugin_EditorRequiresKeyboardFocus set in my pluginchahracteristics file.

i create my appManager in the plugin constructor (the fitler no the UI class)

applicationCommandManager = new ApplicationCommandManager();

then in my UI editor constructor i do:

setWantsKeyboardFocus (true);
commandManager->registerAllCommandsForTarget (this);
setApplicationCommandManagerToWatch (commandManager);

my UI editor class is a subclass of: MenuBarModel, ApplicationCommandTarget, ChangeListener, FileDragAndDropTarget, AudioProcessorEditor
and that’s it

[atom]

also i mentioned this some time ago, but when setting a default value for a constructor parameter it gets declared in both the class definition and implementation witch causes a compiler error (re-definition).

[atom]

any ideas anyone ? maybe i’m doing something so obviously wrong i just can’t see it (it’s often the case).

[jules]

It all looks focus-related, I expect that the plugin window just isn’t getting focused until you click inside it, but TBH I’m not surprised that there could be focus issues when trying to use a menu bar in a plugin, it’s quite complicated when you’ve got host/plugin windows all mixed together like that. I’ll try to take a look as soon as I can.

[atom]

I got some feedback from users, this affects also MAC builds, in both VST and AU versions, i got reports from people using LOGIC and i checked that in Live and it has the same problem.

[steffen]

I’m in the same boat, having a PluginEditor that extends ApplicationCommandTarget and though I tried everything mentioned in this thread, all menu-items for commands implemented by the PluginEditor are disabled until I click anywhere in the plugin.

This doesn’t seem to be host-specific as it is the exact same behaviour for at least ableton live (win/mac), logic 8&9 (mac) and dp6 (mac).

things I tried include:

• explicitly calling ApplicationCommandManager::commandStatusChanged after my PluginEditor is created
• explcitly calling MenuBarModel::menuItemsChanged() after my PluginEditor is created

did anyone find a solution to this issue yet?

[steffen]

I was able to work around this issue by explicitly grabbing the keyboard focus from the plugin-editor. The tricky bit was that it did not work when called from inside the editor’s constructor, so I used a timer to delay the call:

MyPluginEditor::MyPluginEditor
{
    [...]
    startTimer(20);
}

void MyPluginEditor::timerCallback()
{
    grabKeyboardFocus();
    stopTimer();
}