Site navigation

LookAndFeel vs Plugins

General JUCE discussion
#1

I bet this is a basic question, still, I can’t seem to understand how this works. :oops:

I created my own newLookAndFeel class. I add it by using the following code:

newLookAndFeel = new NewLookAndFeel(); getLookAndFeel().setDefaultLookAndFeel (newLookAndFeel);

It works without problems, until you add multiple instances of the PlugIn and try to delete one.

How should I proceed with deleting the newLookAndFeel object? If I try on the Editor Destructor, after using getLookAndFeel().setDefaultLookAndFeel (0); - it crashes the other PlugIn Instance. So I’m clearly doing something wrong.

If I never delete newLookAndFeel, everything works, but doesn’t that leave memory leaks?

Any advice would be much appreciated. Thanks.

Wk

#2

What I tend to do is to make my custom look and feel inherit from DeletedAtShutdown, then you don’t have to worry about it leaking.

(And if you make it a singleton, you’d also avoid each plugin wasting time creating a new instance of it)

#3

Jules, thank you so much, I will check all this out.

I need to learn about Singleton, as I have no clue on what that is. :oops: I will google about this, maybe I already do this and even don’t know. :lol:

Wk

#4

You’ve probably used them before! Have a look in juce_Singleton.h

#5

Drats, sadly my code is leaving something behind when I close and open the editor. I will have to check things out again…

Wk

#6

Singleton looks interesting, never used that one before. I will have to learn that, but in the meanwhile, does the following code look stupid?

static bool didNewLook = false; if (!didNewLook) { didNewLook = true; newLookAndFeel = new NewLookAndFeel(); } else { newLookAndFeel = (NewLookAndFeel*)&getLookAndFeel(); }

With the code above, newLookAndFeel gets created only once. And since I inherit from DeletedAtShutdown, it doesn’t leak anymore. But something else is leaking, so I will have to hunt that one down. :wink:

Wk

#7

Ok, EVERYTHING is good now. Unless my single-instance code is totally bad. :oops: Since this is a Windows only app, for now, this should do the trick for the time…

Jules, thank you so much again, as always!

I plan on revisiting my entire Treeview code to make it public. I also want to add a few more options to it, with more keyboard shortcuts. 8) I just need to clean up the code so people don’t laugh at it… :lol:

Wk

#8

Well, I wouldn’t do it like that…

All you need is:

[code]class NewLook : public LookAndFeel, public DeletedAtShutdown
{
juce_DeclareSingleton (NewLook)
etc…
}

[/code]
and then just call:

…as often as you like.

#9

Ahh, I got it now. Thanks a bunch! :mrgreen:

Here’s how it works now. There are 2 things to do, use:

juce_DeclareSingleton (NewLookAndFeel,true)

In the class. (header: .h file) And in the cpp file, add:

juce_ImplementSingleton (NewLookAndFeel)

One will add to the class definition, and the other will add the lock and getinstance code.

Cool, its already working! 8)

Thanks again.

Wk

#10

Is that a new type of behavior? I never had to do anything like this… but I’m also still on the 1.46 version, I have to shamefully admit.

#11

No, nothing new there…

#12

[quote] static bool didNewLook = false;
if (!didNewLook)
{
didNewLook = true;
newLookAndFeel = new NewLookAndFeel();
}
else
{
newLookAndFeel = (NewLookAndFeel*)&getLookAndFeel();
}
[/quote]

For those who use this kind of coding.
Its a bad idea actually, y to simply keep one static variable

we can go this approach

NewLookAndFeel* GetNewLookAndFeel()
{
if ( newLookAndFeel != 0L ) // initialize to NULL in constructor 
{
      newLookAndFeel = new NewLookAndFeel(); 
} 
return newLookAndFeel;
}
#13

Much better to just let the singleton macros handle all this for you. Singletons aren’t always quite as simple as they sound - have a look through my singleton code and you’ll see there are a few edge cases that need to be dealt with, especially if you’re using threads.

…I often see people write that, and it annoys me - why “0L”? It’s the wrong type - you don’t want to compare a pointer to a long, do you? Sure, the compiler will ignore it, internally casting the long to a pointer, but why bother adding a suffix if it’s not even the right one!?

#14

Correction is needed Jules

The code has to be

newLookAndFeel == 0L

instead of

newLookAndFeel != 0L

I just use “0L” it not to confuse with normal int variable and pointers.

If compiler dose not bother y we should be bothered.

Thanks
Godwin

#15

Ok, I know I’m a bit pedantic, but comparing a pointer to an int looks extremely ugly to me, and I’m a little surprised that compilers don’t warn about it. After all, this would be an error:

long myLong = 0L; if (myPointer == myLong)

If you really want to put an explicit type there, then “(void*) 0” would make more sense!

#16