Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: using Scripts with GUIKit (bug?)

  • To: mathgroup at smc.vnet.net
  • Subject: [mg57582] Re: [mg57436] using Scripts with GUIKit (bug?)
  • From: Jeff Adams <jeffa at wolfram.com>
  • Date: Wed, 1 Jun 2005 06:03:36 -0400 (EDT)
  • References: <200505280938.FAA21636@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

On May 28, 2005, at 4:38 AM, Brett Patterson wrote:
> Hi,
>
> When should a Script[...] be use in a GUIKit Widget expression?
>
> For example, in the documentation for the ComboBox widget there is
> ambiguity about whether
>    "items" -> {"one", "two"}
> or
>    "items" -> Script[{"one", "two"}]
> is correct. I've tried both and they both seem to work.

There was a time in the early beta releases of GUIKit that raw
lists like {"one", "two"} were not supported as basic elements
of the GUIKit definition expression or converted to the underlying
Java native arrays at runtime, while wrapping a Script[] block is 
always a safe way of
making sure that any Mathematica result value will result in either a 
Java object
or a converted Java object, in this case a native Java String[] array.


> Also, is the scope (context) of ALL Script blocks the same in a Widget
> expression, even if there are Dialog widgets that are shown/disposed
> during operation of the GUI?

Yes, all Script[] blocks within a single GUIKit expression share the 
same
dynamically created context. However if one definition calls
a Widget["SomeOtherExpression"] which resolves to a completely separate
.m file with its own Script[] expressions they resolve to their own 
shared child context.
This is done to allow one to encapsulate a completely self contained 
reusable Widget definition
on a per-expression basis where all Scripts[] of one expression are 
shared, and not just
encapsulation on a per Widget["name, {...}] subexpression.
This model is not unlike how all javascript functions are shared and 
executed
within one single context of one .html expression.

> Finally, this all relates to an infuriating bug I have. I have a main
> Panel widget that contains a Dialog widget that is shown when a Button
> in the Panel is clicked. The Dialog has a ComboBox called "sPlotCombo".
> In the main Panel widget definition, I have a function definition in a
> Script that uses the expression
>    PropertyValue[{"sPlotCombo", "selectedItem"}].
> However, this is causing the evaluation of the Panel to hang. If I
> comment out all such expressions, the Panel evaluates and displays, but
> if I include those expressions, the then evaluation just hangs and no
> GUI is displayed and I have to Quit the Kernel.
>
> Any clues as to the cause and solution of this bug would be warmly
> welcomed!

Would it be possible to send the complete expression involved?
It would be easier to debug this and run this myself.

One potential problem is that this event could be triggering a second 
Mathematica kernel evaluation
that cannot complete until an existing Script[] expression is being 
evaluated.

It is also possible that the default single-threaded Java execution of 
the GUI is causing the perceived hang
because if the dialog is shown modal to the rest of the Java windows 
asking for the selectedItem of a different window
that is not the current modal window could possibly block.
But it might be easier to figure out the source of your problem by 
seeing more code.

Jeff Adams
Wolfram Research


  • Prev by Date: Re: Related quastions. Question 2
  • Next by Date: Re: Re: making an animated picture from many pictures
  • Previous by thread: Re: Complex Oddity
  • Next by thread: Re: Re: making an animated picture from many pictures