How to make GS Widgets

[Ulf Wiger (AL/EAB)]

Hello Cedric,

Nice.

Let me dodge your questions and instead volunteer a suggestion
on a minor aspect of programming style:   (:

	if
		is_tuple(SuppliedColor), size(SuppliedColor) == 3 ->
			{Red, Green, Blue} = SuppliedColor;
		true ->
			{Red, Green, Blue} = {0, 0, 0}
	end,

If we tell the compiler to be a bit picky, it will warn against 
this type of code:

erlc -W +warn_export_vars mywidgets.erl
/home/etxuwig/work/erlang/mywidgets.erl:44: Warning: variable 'Red' exported from 'if' (line 35)
/home/etxuwig/work/erlang/mywidgets.erl:47: Warning: variable 'Green' exported from 'if' (line 35)
/home/etxuwig/work/erlang/mywidgets.erl:50: Warning: variable 'Blue' exported from 'if' (line 35)

A very straightforward fix is:

   {Red, Green, Blue} =
	if
		is_tuple(SuppliedColor), size(SuppliedColor) == 3 ->
			SuppliedColor;
		true ->
			{0, 0, 0}
	end,

Personally, I was a bit surprised that the compiler doesn't actually 
issue a warning when compiling mywidgets.erl, since Red, Green and 
Blue are in fact referred to after the 'if' expression.

>From the man page for 'compile':

"warn_export_vars 
Causes warnings to be emitted for all implicitly exported variables referred to 
after the primitives where they were first defined. No warnings for exported 
variables unless they are referred to in some pattern, which is the default, 
can be selected by the option nowarn_export_vars. "

After a short experiment, I understand that the operative phrase is 
"in some pattern", but it's too early in the morning for me to grasp
why one needs to issue warnings when implicitly exported variables are
used in patterns, and not when they are used in expressions.

/Uffe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Cedric Shock
> Sent: den 15 april 2004 07:12
> To: erlang-questions@REDACTED
> Subject: How to make GS Widgets
> 
> 
> Hello,
> 
> I have found a way to implement custom widgets for GS. Here's 
> how it works:
> 
> Spawn and link a new process for the widget. The new process (widget) 
> will need at least the process id of its creator, and the gs 
> reference 
> to the container it will be placed in. Wait for the widget to respond 
> with a gs reference to the frame it has made to contain itself. The 
> widget will be able to manipulate this frame, and will 
> recieve all the 
> events from this frame. The widget process can now send event-like 
> messages to the calling process. The widget process should 
> monitor the 
> process that created it, so that it will exit when its creator exits.
> 
> The widget can provide an interface for feedback or control from the 
> creating process. This method requires the creating process to posess 
> the process id of the widget to fully manipulate it.
> 
> For a small example of how this works, see the attachments.
> 
> Are there any serious issues with taking advantage of this 
> "undocumented 
> feature" (the routing of events to the process that created the gs 
> widget) to implement custom widgets? Will a process that is 
> waiting at a 
> receive clause use processor time, or will erlang put off 
> executing it 
> until there is a new message to consider?
> 
> Thank you very much for your feedback,
> 
> Cedric Shock
> 
>