Programming forms in cadence

G

Guenther Sohler

Guest
I have been programming forms the last days.
This process is as follows, that the user fills in some fields and
presses "OK".
Then the callback is called and processes the input given.

The issue is following: if the user gives incorrect data, the callback
cannot execute correctly and has to quit. Thus the user has to start
the form again to reenter all the data.
How can this be prevented ?

if the callback detects invalid data, how can the user be sent back to the
already-filled-out form, correct it and try "OK" again ?


rds
 
On Aug 10, 11:42 am, Guenther Sohler <guenther.soh...@wipro.com>
wrote:
I have been programming forms the last days.
This process is as follows, that the user fills in some fields and
presses "OK".
Then the callback is called and processes the input given.

The issue is following: if the user gives incorrect data, the callback
cannot execute correctly and has to quit. Thus the user has to start
the form again to reenter all the data.
How can this be prevented ?

if the callback detects invalid data, how can the user be sent back to the
already-filled-out form, correct it and try "OK" again ?

rds
Isn't this why there is always an 'Apply' button in Cadence forms?
This would apply the data without closing the window.
--
Svenn
 
Guenther Sohler wrote:
I have been programming forms the last days.
This process is as follows, that the user fills in some fields and
presses "OK".
Then the callback is called and processes the input given.

The issue is following: if the user gives incorrect data, the callback
cannot execute correctly and has to quit. Thus the user has to start
the form again to reenter all the data.
How can this be prevented ?

if the callback detects invalid data, how can the user be sent back to the
already-filled-out form, correct it and try "OK" again ?


rds
From memory, FWIW: In the past, I have circumvented this problem by
storing the form handle (the same one passed to hiDisplayForm and returned
by hiCreateAppForm) in a global variable. In my form initialization
program, I simply test to see if the global variable is defined and contains
a valid form. If it does, then I do not recreate it. I simply display it
again. Something like:

unless(boundp('myGlobalForm) &&
hiIsForm(myGlobalForm) &&
hiIsInstantiated(myGlobalForm) (or similar form sanity checks)

myGlobalForm = hiCreateAppForm(...)

)

hiDisplayForm(myGlobalForm)



The problem with this is that you can only have one version of the form
displayed at any given time. Activating the form again (through menubar,
bindkey, etc.), simply raises the already open form.


I believe you have to use a variant of gensym() for the formName and either
randomize or localize the form handle being displayed to open multiple
forms. Of course, you'll lose the current data.

In a former life, I wrote a form-template/save-state package. It's not too
hard to write, and it's very powerful to have all your forms linked under a
single interface, which can load and apply templates on a cell basis.

HTH

Trevor

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
 
In article <pan.2007.08.10.09.42.51.393398@wipro.com> Guenther Sohler <guenther.sohler@wipro.com> writes:
I have been programming forms the last days.
This process is as follows, that the user fills in some fields and
presses "OK".
Then the callback is called and processes the input given.

The issue is following: if the user gives incorrect data, the callback
cannot execute correctly and has to quit. Thus the user has to start
the form again to reenter all the data.
How can this be prevented ?

if the callback detects invalid data, how can the user be sent back to the
already-filled-out form, correct it and try "OK" again ?
When the form is created, pass:

?unmapAfterCB t

as one of the arguments to hiCreateAppForm().

This ensures the form is not unmapped until after the form callback. If,
during the callback, you determine the form should stay up, call:

hiSetCallbackStatus( r_form nil )

before returning. If it is OK and should close, call:

hiSetCallbackStatus( r_form t )

-Pete Zakel
(phz@seeheader.nospam)

The Abrams' Principle:
The shortest distance between two points is off the wall.
 

Welcome to EDABoard.com

Sponsor

Back
Top