Hi Tomas,
> This way it should work as the only time when *Radio is important is
> when a form is being built.
You could store it in a property 'radio' in the form (e.g. *Top). In
this way it will be empty for a new form, and will be found and reused
when a form is reloaded during a POST event.
> I did not know about the id property and I am not sure what does it
> contain exactly. If it contains the number which is rendered in html
> in the name attribute as <id>: name="*Gui(+<id>)" then 1st could be
> directly the first gui radio button in the group, its id property used
> for html rendering and (length (get *Top 'gui)) could be dropped off
> the *Radio assoc list.
Yes. You could move the (super) in the 'T' method to the beginning
(dm T (Grp Xval Lbl)
(super)
...
so that 'id' is set in the object. As it starts with 1, you also
could use
(caddr (: 1st))
instead of
(+ 1 (caddr (: 1st)))
in the 'show>' method.
BTW, did it work in your tests? In the version you posted, there
was a blank in 'name="*Gui(+X) ", so that the group connection was
not recognized.
> > 2. Why do you distinguish in the 'show>' method between directly calling
> > '<radio>', and a "hand-made" version?
> It is very important, because all radio buttons in one group must have
> the same 'name' attribute (otherwise a browser would not know they
True, but wouldn't something like
(<radio>
(if (: 1st)
(cons '*Gui (caddr @))
"Var" )
work?
Let me try it.
However, one major problem remains: I think it will not work when
JavaScript events are involved, as "lib/form.js" is not prepared for
that. Anyway, I'll try :-)
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
