how to display to app forms at once?

J

Jimka

Guest
Does anyone know how i can define and display two GUI froms
programatically?
It is easy interactively. You simply define the forms, and from the
CIW call hiDisplayForm
twice, once for each form. the first hiDisplayForm displays the form
and waits, but
you can enter another command in the CIW.

However, if you call hiDisplayForm twice from a SKILL function while
neither form
is already displayed, then only one is displayed, and when the user
presses
OK/Cancel on that form, then the next hiDisplayForm is called.

I have a solution (in the next post) but it is not very pretty.
 
Here is a function that will display one or more hi GUI forms
simultaneously. It depends on a behaviour of the load function
which i discovered accidentally. I do not know if the behavior
is documented or dependable. But the accidentally discovered
behavor is that if you call hiDisplayForm multiple times
in a file, and load the file, then hiDisplayForm either does not
wait, or the load function recognizes then and continues loading
just as if the user were typing the same SKILL into the CIWindow.
It appears that load, treats the input file identically to
input read from the CIWindow.

The function, creates code, writes it to a file, then loads the file.
This is ugly, and i'd love someone to suggest a way to
do this without having to write to a tmp file.

Does anyone know if this behavior is dependable
or advertised?

;; This function takes one or more form names (as symbols) and
;; displays them all simultaneously.
;; E.g., (display_multiple_forms 'form1 'form2)
(defun display_multiple_forms (@rest forms)
(let ((fileName (makeTempFileName "/tmp/XXXXX")))
(let ((fp (outfile fileName)))
(foreach form forms
(println `(hiDisplayForm ',form) fp))
(close fp))
(load fileName)
(deleteFile fileName)))
 
On 24 Dec 2005 05:25:58 -0800, "Jimka" <jimka@rdrop.com> wrote:

Here is a function that will display one or more hi GUI forms
simultaneously. It depends on a behaviour of the load function
which i discovered accidentally. I do not know if the behavior
is documented or dependable. But the accidentally discovered
behavor is that if you call hiDisplayForm multiple times
in a file, and load the file, then hiDisplayForm either does not
wait, or the load function recognizes then and continues loading
just as if the user were typing the same SKILL into the CIWindow.
It appears that load, treats the input file identically to
input read from the CIWindow.

The function, creates code, writes it to a file, then loads the file.
This is ugly, and i'd love someone to suggest a way to
do this without having to write to a tmp file.

Does anyone know if this behavior is dependable
or advertised?

;; This function takes one or more form names (as symbols) and
;; displays them all simultaneously.
;; E.g., (display_multiple_forms 'form1 'form2)
(defun display_multiple_forms (@rest forms)
(let ((fileName (makeTempFileName "/tmp/XXXXX")))
(let ((fp (outfile fileName)))
(foreach form forms
(println `(hiDisplayForm ',form) fp))
(close fp))
(load fileName)
(deleteFile fileName)))
Click to expand...
It's a side effect - in fact we had a customer reporting such behaviour as a
bug... (but it won't be fixed). However, it is not (as far as I know)
documented, and you should not depend on it (it could well be changed in
future). It's also pretty ghastly as you say...

The best solution is to the the ?dontBlock t argument when you create the form
in the first place, and then displaying the form will not block, and so you can
display as many as you like...

Another approach (if the forms already exist, and cannot be recreated with
?dontBlock for some reason) is to use hiRegTimer() to display the forms (with a
time of 0 tenths of a second, say).

Andrew.
 
In article <1135430173.471475.278780@o13g2000cwo.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:
Does anyone know how i can define and display two GUI froms
programatically?
It is easy interactively. You simply define the forms, and from the
CIW call hiDisplayForm
twice, once for each form. the first hiDisplayForm displays the form
and waits, but
you can enter another command in the CIW.

However, if you call hiDisplayForm twice from a SKILL function while
neither form
is already displayed, then only one is displayed, and when the user
presses
OK/Cancel on that form, then the next hiDisplayForm is called.
Click to expand...
You are using blocking forms, so the code execution is suspended on each until
you close each form (and you have to close the second form before closing the
first form will cause it to return to program execution).

To avoid this, pass "?dontBlock t" as an argument to hiCreateAppForm() for at
least the first form).

-Pete Zakel
(phz@seeheader.nospam)

"Probably the best operating system in the world is the [operating system]
made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977
 
Do you know of any reason why this behavior should not be documented.
It could potentially be very powerful. Especially if there were a more
lispy interface such as load_from_list, or load_from_string.
It seems reasonable that loading a file have the same semantics as
typing the same
contents into the CIWindow.

Yes i know a little about ?dontBlock, but doesn't that have to be given
on form definition?
I do not have the source code to all form definitions, or can
?dontBlock be given
on form instantiation even if the definition of the form did not
provide it?
 
On 28 Dec 2005 16:04:18 -0800, "Jimka" <jimka@rdrop.com> wrote:

Do you know of any reason why this behavior should not be documented.
It could potentially be very powerful. Especially if there were a more
lispy interface such as load_from_list, or load_from_string.
It seems reasonable that loading a file have the same semantics as
typing the same
contents into the CIWindow.
Click to expand...
I think one reason would be that it would have to work that way forever - and we
might not want to tie ourselves down. This definitely smacks of side effect
behaviour, rather than something is designed to work this way - and it is pretty
inelegant.

Yes i know a little about ?dontBlock, but doesn't that have to be given
on form definition?
I do not have the source code to all form definitions, or can
?dontBlock be given
on form instantiation even if the definition of the form did not
provide it?
Click to expand...
No, it has to be defined at form creation time. But you can use the hiRegTimer()
approach that I suggested to allow multiple blocking forms to be launched at
once (I'm not talking about "modal" type blocking, but blocking in the sense
that the hiDisplayForm() does not return).

Regards,

Andrew.
 
In article <1135814658.657921.45080@f14g2000cwb.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:
Do you know of any reason why this behavior should not be documented.
It could potentially be very powerful. Especially if there were a more
lispy interface such as load_from_list, or load_from_string.
It seems reasonable that loading a file have the same semantics as
typing the same
contents into the CIWindow.
Click to expand...
Loading a file has the same semantics, but not the same behavior. When
a blocking operation is instigated, a new Skill top-level is started. That
new top-level will continue reading an input file (or replay file), but the
new top-level cannot return to a procedure -- that return only happens when
the blocking call returns.

That's why the behavior is different.

Yes i know a little about ?dontBlock, but doesn't that have to be given
on form definition?
I do not have the source code to all form definitions, or can
?dontBlock be given
on form instantiation even if the definition of the form did not
provide it?
Click to expand...
No, ?dontBlock has to be supplied when the form is created.

Another workaround is to use hiRegTimer() calls to invoke the forms, but
that is not a recommended way to do it, since calling blocking operations
from a timer callback is usually not a good idea.

-Pete Zakel
(phz@seeheader.nospam)

The invariable mark of wisdom is to see the miraculous in the common.

- Emerson
 
Loading a file has the same semantics, but not the same behavior. When
a blocking operation is instigated, a new Skill top-level is started. That
new top-level will continue reading an input file (or replay file), but the
new top-level cannot return to a procedure -- that return only happens when
the blocking call returns.
Click to expand...
I do not see any difference. If i open two forms from in input file,
then two
forms open and consequently a new skill top-level is started.

If i open two forms from the CIWindow, then two forms open and
consequently a new skill top-level is started.

Is there something i'm missing here? It seems to me that they have the
same behavior exactly. Where is the difference you see Pete?
 
In article <1135990073.707809.83730@g44g2000cwa.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:
Loading a file has the same semantics, but not the same behavior. When
a blocking operation is instigated, a new Skill top-level is started. That
new top-level will continue reading an input file (or replay file), but the
new top-level cannot return to a procedure -- that return only happens when
the blocking call returns.

I do not see any difference. If i open two forms from in input file,
then two
forms open and consequently a new skill top-level is started.

If i open two forms from the CIWindow, then two forms open and
consequently a new skill top-level is started.

Is there something i'm missing here? It seems to me that they have the
same behavior exactly. Where is the difference you see Pete?
Click to expand...
The difference is that a new top-level cannot return.

A new top-level will continue reading a file, so in-line blocking calls
will not block the execution of further statements in the file.

I cannot explain it any clearer than that.

-Pete Zakel
(phz@seeheader.nospam)

"Slang is language that takes off its coat, spits on its hands, and goes
to work."
 
Hi pete, are you sure you are not mistaken here?

The difference is that a new top-level cannot return.
Click to expand...
This is not a difference that i can see: the new top-level cannot
return in either case,
neither when started from the CIW nor when started from a file load.

When loading a file, after the first form has been
poped up, a NEW top level continues reading the file and pops up the
second form.

When reading from the CIW, a NEW top level continues reading after the
first form
is poped up, and that new top level pops up the second form.

In both cases neither top-level can return until the user OKs or
Cancels the form.
In both cases a different top level pops up each form.

I do not see any difference.

-jim
 
Yes pete, this illustrates my point. Entering into the CIW works
exactly
the same as reading the code from a file. There does not seem to be
any difference
that I can detect.

If you enter these two lines into a file or type them into the CIW, the
same thing will
happen:

MyTestString = "before" hiDisplayForm(<blocking form>) MyTestString =
"after"
printf( "MyTestString = %s\n" MyTestString)

I believe you claimed:
Loading a file has the same semantics, but not the same behavior.
Click to expand...
Can you think of an example that works differently if you load it from
a file
or if you type the same thing into the CIW?
My experimentation has shown they have the same behavior.

-jim
 
In article <1136234180.075086.69330@f14g2000cwb.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:

Can you think of an example that works differently if you load it from
a file
or if you type the same thing into the CIW?
My experimentation has shown they have the same behavior.
Click to expand...
Yes, they do.

However, loading from a file and executing a procedure works differently
with relation to blocking behavior for the same reason that the string
assignment won't occur until the form is closed.

-Pete Zakel
(phz@seeheader.nospam)

"This `telephone' has too many shortcomings to be seriously considered as a
means of communication. The device is inherently of no value to us."

-Western Union internal memo, 1876
 
In article <43b99a2e$1@news.cadence.com> pxhxz@cadence.com (Pete nospam Zakel) writes:
In article <1136234180.075086.69330@f14g2000cwb.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:

Can you think of an example that works differently if you load it from
a file
or if you type the same thing into the CIW?
My experimentation has shown they have the same behavior.

Yes, they do.

However, loading from a file and executing a procedure works differently
with relation to blocking behavior for the same reason that the string
assignment won't occur until the form is closed.
Click to expand...
To followup on my followup -- think of a procedure as the same thing as
entering all the statements you want to execute on the same line:

hiDisplayForm(<blocking form>) hiDisplayForm(<another form>)

entered on one line will only display the second form after the first form
is closed.

A procedure works the same way, even when the statements are on different
lines because they are one "execution unit" (to coin a phrase).

-Pete Zakel
(phz@seeheader.nospam)

"All television is children's television."
-Richard P. Adler
 
Yes, loading a file seems the same as entering into the CIW,
but evaluating a procedure that contains the content of that file
is different. That was indeed the point of my first posting.

And if you want to popup two (or more) forms (which you did not
write, and for which you do not have the source code) from a single
procedure, how can you do it?

My proposed solution was have the procedure actually print to
a file and load it.


;; This function takes one or more form names (as symbols) and
;; displays them all simultaneously.
;; E.g., (display_multiple_forms 'form1 'form2)
(defun display_multiple_forms (@rest forms)
(let ((fileName (makeTempFileName "/tmp/XXXXX")))
(let ((fp (outfile fileName)))
(foreach form forms
(println `(hiDisplayForm ',form) fp))
(close fp))
(load fileName)
(deleteFile fileName)))
 
In article <1136071912.205948.276090@g49g2000cwa.googlegroups.com> "Jimka" <jimka@rdrop.com> writes:
Hi pete, are you sure you are not mistaken here?

The difference is that a new top-level cannot return.

This is not a difference that i can see: the new top-level cannot
return in either case,
neither when started from the CIW nor when started from a file load.
Click to expand...
Try this:

enter (all in one line) the following into the CIW:

MyTestString = "before" hiDisplayForm(<blocking form>) MyTestString = "after"

Now enter:

printf( "MyTestString = %s\n" MyTestString)

while the form is still up and you'll see the value of MyTestString is
"before". That is because the hiDisplayForm() is blocked and won't return to
the statement that sets MyTestString to "after" until you close the form.

If you put the above two lines into a procedure:

procedure( MyTestProcedure()
MyTestString = "before" hiDisplayForm(<blocking form>) MyTestString = "after"
printf( "MyTestString = %s\n" MyTestString)
)

and then call the procedure the printf line will not be executed until after
the form is closed and MyTestString has been set to "after".

If you put the two lines entered originally into a file and load or replay the
file, they will act just as if you had entered them into the CIW.

-Pete Zakel
(phz@seeheader.nospam)

"Now and then an innocent person is sent to the legislature."
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top