On Friday 28 April 2006 10:37, Istvan Varga wrote:

> On Friday 28 April 2006 02:43, Michael Gogins wrote:
> 
> > Putting dummy widgets in so as not to break widget orcs is a good idea.
> 
> It needs some maintenance, though (fortunately new widgets do not seem to
> be added frequently), but at least the program will not hang or crash.
> You can use FLTK widgets, however, just turn off "perform in a separate
> thread". This will also enable the graph displays.
> An alternative way for controlling the widget opcodes could be to implement
> some way of communication between the host application and the opcodes
> (e.g. using the csound*GlobalVariable interface), to make it possible to
> disable the opcodes, change the threading behavior, etc.

This is now done (quoting from ChangeLog):

        * Made it possible to control the behavior of the FLTK plugin
          from the host application. This can be done with the following
          code between calling csoundPreCompile() and csoundCompile():
            CSOUND *csound;
            ...
            csoundCreateGlobalVariable(csound, "FLTK_Flags", sizeof(int));
            *((int*) csoundQueryGlobalVariable(csound, "FLTK_Flags")) = flags;
          where 'flags' can be the sum of any of the following values:
            1: disable widget opcodes
            2: disable FLTK graphs
            4: disable the use of a separate thread for widget opcodes
            8: disable the use of Fl::lock() and Fl::unlock()
           16: disable the use of Fl::awake()
          additionally, after calling csoundCompile(), the same variable
          can be checked to find out if graphs or widget opcodes are used:
           32: FLrun opcode was called
           64: callbacks for FLTK graphs are set