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]

Reply via email to