I am working on an highly modulized plug in library. Its still on windows. Basically, all my code is inside a DLL file. This DLL will be loaded and used if needed by any type of host application running any type of code written in whatever language and windowing system they run. And the code inside the modules in the plug in all have their seperate gui and they need to be able to run in parallel on different threads. Its probably a stupid question but can I use juice for this inside a dll file?
Right now I am using windows resource files which are small, fast and does not require any additional dependencies but they aren’t portable and are pain to work with. I tried gtk, fox and wx but I am liking juice over them because of its size and appearance. So I also wanted to ask if juice have high level layout managers like Table Layout or Paned setups like gtk/FOX/swing etc to automatically laying out things and resizing them when window resizes?
…ahem… the name is “juce”, but thank you for trying to correct my spelling!
If you’ve seen the demo app then you should have noticed the tables, panes, etc. that it can do.
As for running in a DLL, well yes, you can build it one - audio plugins are just DLLs, and juce supports them, of course. You might hit some snags if you start trying to pass objects between DLLs or share the message thread, but there’s no c++ framework in existence that would avoid those kinds of problem.
Oh sorry about the name thing. I’ve been having a lot of fun with it It’s just been great.
I also think there is a bug or something regarding updateContent() and the selected item in TableListBox. Not sure if it applies to normal list boxes. Didn’t need to try them yet. It doesn’t seem to show changes before the selected item is unselected.
Anyways, I was in need of a modeless window. Is putting it on a different thread with another thread and another JUCEApplication the best option? I tried putting it in another thread with runModalLoop but it acts weird and I guess my main juce thread is kinda busy from doing all the processing.
on listboxes at least, calling update only checks to see if the number of items has changed. If they have, a repaint will be triggered. Otherwise no action will be taken. This can catch you rout if a list changes but the number of items remains the same. It’ll also catch you out if you’re just trying to refresh the view for one or more items in an unchanged list. If you want to redraw your item(s) use either repaint or the repaint row methods.
I have juce statically linked to my dll plugin. The problem seems to be associated with the application instance. If I open another copy of the program, the problem doesn’t appear most of the times. Well, I’d say there is a 2-3% chance of things acting like that. I have no clue why it happens =(
Wow - that’s very very odd. Never seen anything like it before.
It looks like the glyph cache is picking out the wrong cached image to use, but I can’t see why on earth it would do that. The code for this is in juce_GlyphArrangement.cpp, and it’s old, tried and tested stuff that’s always been really solid.
You’re not doing anything like rendering fonts using different threads, are you?
Should putting things in a different thread cause that? That could probably be it.
I have 3 threads. One thread is exclusively used by JUCE. It starts off after GUI thread and calls main in JUCEApplication. Then there is the GUI thread which takes care of the JUCE thread i.e. starts the thread and calls quit when done etc and makes those windows and runs a modal loop. And there is a third thread which uses some JUCE GUI stuff sometimes; Namely, appending text to the text editors and posting command messages.
So am I having those problems because runModalLoop is being called on a different thread? Should it help to get rid of it? or should I make sure the TextEditor append thing is also done exclusively by the juce thread?
Awesome. Its working perfectly. I haven’t had any issues after putting everything through postCommandMessage. It’s not much of an issue but it would be handy to be able to post at least one optional extra parameter with the command message. Anyways, thanks heaps =)
It’s just been great.
