Ok, FYI:

I finally found out why I was getting stuck with the vtcl combobox.  My command-to-be-called was expecting only one argument (as supplied by the -command option), but the ::combobox2::CallCommand proc sends more than you would expect if you didn't know to look.  The biggest problem was simply that I wasn't being informed of the specified command's failure, so I didn't know where to start looking for the problem.

With vTcl 1.5.2 (and 1.6.x I believe), adding the vTcl Combobox widget inserts all the requisite TCL code into your project encapsulated within the ::combobox2 namespace.  The key line of code is
      uplevel #0 $options(-command) $args
within ::combobox2::CallCommand.  I'd recommend that it be replaced (in the vTcl distribution) with something like
  catch { uplevel #0 $options(-command) $args } r
  if {[regexp {called with too many arguments} $r]} {
   bgerror $r
  }

This is a bit tricky because $r will be the result of the last command in the called proc if successful, and possibly something else if not.  In my case, I populate another listbox's list variable depending on the combobox selection, which can result in a quite lengthy return value and thus a bizarre bgerror dialog.  But at least the above hack would let the first-time user know their command needs an 'args' argument to suck up the extra (and probably undesired) stuff.

Anyway, just thought this might be helpful to someone someday.

Cheers,

-Chris.

~~~~~~~~~~~~~~~~
Chris Bennett
[EMAIL PROTECTED]

------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ vtcl-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/vtcl-user

Reply via email to