iamfromspacebaby

Is it possible to implement a gui progress bar in mxj?

gui-progress-bar-in-mxj

- What position are you starting from, vis-a-vis experience with 

Java/MXJ? (Knowing will make it easier to nudge you in profitable 

- How do you envisage it working? Is this to report on the progress of 

something happening in Java-land or max-land? (If the latter, JSUI or 

In any case, there is a Swing class, JProgressBar. You should check the 

archives for previous discussions of how to get Java gui elements to 

(BTW, has anyone played with SWT in mxj yet?)

> Is it possible to implement a gui progress bar in mxj? 

Questions:
- What position are you starting from, vis-a-vis experience with 
Java/MXJ? (Knowing will make it easier to nudge you in profitable 
directions)

- How do you envisage it working? Is this to report on the progress of 
something happening in Java-land or max-land? (If the latter, JSUI or 
lcd may well involve less heartache).

In any case, there is a Swing class, JProgressBar. You should check the 
archives for previous discussions of how to get Java gui elements to 
behave.

Carl Knott wrote:
> Is it possible to implement a gui progress bar in mxj? 
>


In answer to your questions, I have lots of experience with Java and so so with mxj - its going to work in Java-land, as the patch is loading.. I'm creating 25 Matrices before the patch loads so it takes several seconds... I'll take a look at JProcessBar, thanks :)

> In answer to your questions, I have lots of experience with Java

Good, that makes explaining the main thing to watch about doing gui 

It's important that AWT/Swing things happen in the AWT event thread, not 

the max/mxj thread (due to cocoa /carbon squabbling on the mac), 

otherwise lockups and other badness ensues. Liberal use of 

Carl Knott wrote:
> In answer to your questions, I have lots of experience with Java 

Good, that makes explaining the main thing to watch about doing gui 
stuff in mxj pretty easy:

It's important that AWT/Swing things happen in the AWT event thread, not 
the max/mxj thread (due to cocoa /carbon squabbling on the mac), 
otherwise lockups and other badness ensues. Liberal use of 
SwingUtilities.invokeLater() is the key.

On 3 Aug 2007, at 13:07, Owen Green wrote:

> It's important that AWT/Swing things happen in the AWT event 

> thread, not the max/mxj thread (due to cocoa /carbon squabbling on 

> the mac), otherwise lockups and other badness ensues. Liberal use 

> of SwingUtilities.invokeLater() is the key.

If all you want is a progress bar, why not just create a single-row, 

non-clickable, multiSlider in the MAX world and feed it from your MXJ 

So far, any time I've needed some graphical interaction with an MXJ 

object, I've just used MAX and/or JavaScript GUI to build the widgets.

> It's important that AWT/Swing things happen in the AWT event  
> thread, not the max/mxj thread (due to cocoa /carbon squabbling on  
> the mac), otherwise lockups and other badness ensues. Liberal use  
> of SwingUtilities.invokeLater() is the key.

If all you want is a progress bar, why not just create a single-row,  
non-clickable, multiSlider in the MAX world and feed it from your MXJ  
object?

So far, any time I've needed some graphical interaction with an MXJ  
object, I've just used MAX and/or JavaScript GUI to build the widgets.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


Gui progress bar in mxj?