A better picklist implementation
Lan
have fields that are to be filled from tables only. There is a button
beside the entry that drops a picklist populated from a table of
permitted values.
My code works but is ugly in presentation. I cannot position the
picklist over the screen with any accuracy. The toplevel into which I
put the picklist has large gray space voids. And I have a timing issue
on the button that bakes it dissappear (I need to delay before
destroying or it locks up), which disturbs me.
This is such a common requirement that I have to believe that it has
been solved elegantly somewhere, if only I could find the example. I
believe I have every book on Tcl/Tk written, but I've failed to find a
code snippette that shows me where my errors are.
In a related question, one (and only one) of my picklists -- the one
for the record find -- pulls multiple fields. I'm having to parse, pad,
and assemble the display line, and again, someone has undoubtedly
written something (a megawidget?) for just this purpose. What would it
be? How does one find these things?
My code is available (with blushes) if necessary.
TIA,
~Lan Barnes
tun...@yahoo.com
> This is such a common requirement that I have to believe that it has
> been solved elegantly somewhere, if only I could find the example. I
> believe I have every book on Tcl/Tk written, but I've failed to find a
> code snippette that shows me where my errors are.
The best way would be to post a snippet of your code so others can help
right away. Later, I can also extract something similar that I had
done a while ago.
> In a related question, one (and only one) of my picklists -- the one
> for the record find -- pulls multiple fields. I'm having to parse, pad,
> and assemble the display line, and again, someone has undoubtedly
> written something (a megawidget?)
Yes, there are several, both in pure Tcl and compiled extension. You
may start with http://wiki.tcl.tk/5527 or
http://tktable.sourceforge.net/.
Lan
Here is the code for one pick list button with all the usual disclaimer
about my inadequate programming skills and commenting:
proc pick_request_type {} {
global request_type db DisplList ProgramMessage
set DisplList [list ""]
pg_select $db "SELECT * FROM request_types ORDER BY
request_type;" resultArr {
lappend DisplList $resultArr(request_type)
}
toplevel .topl -width 0 -height 0
listbox .topl.picklist -width 0 -height 0
button .topl.b -padx -5 -pady -4 -text x -command {destroy
.topl}
set cntr 0
foreach ListItem $DisplList {
if {$ListItem eq ""} {continue}
.topl.picklist insert end $ListItem
incr cntr
}
set ProgramMessage "Select the field contents"
set ListChoice -1
bind .topl.picklist <ButtonRelease-1> {
set ListChoice [.topl.picklist curselection]
set request_type [lindex $DisplList [expr $ListChoice +
1]]
clearMessage
after 10 {destroy .topl}
}
pack .topl.b .topl.picklist -side bottom
set pick_x [winfo x .button#8]
set pick_y [winfo y .button#8]
wm geometry .topl 100x[expr $cntr * 25]+[expr $pick_x -
100]+[expr $pick_y + 50]
wm overrideredirect .topl 1
grab .topl
}
tun...@yahoo.com
> tun...@yahoo.com wrote:
> > Lan wrote:
>
> Here is the code for one pick list button with all the usual disclaimer
> about my inadequate programming skills and commenting:
No problem! That is why this forum exists.
I see that you are truly rolling your own picklist. Even thought the
terminology is a bit different, you may want to check the tk_optionMenu
command. This will simplify your code greatly, and you can use bind to
automate the updates from the database. Let us know how it goes or if
you need more help.
Bruce Hartweg
Donald Arseneau
> put the picklist has large gray space voids. And I have a timing issue
> on the button that bakes it dissappear (I need to delay before
> destroying or it locks up), which disturbs me.
That looks like not a timing issue, but a bindtags issue. Since there
are other bindings to be executed on ButtonRelease, you either can't
destroy the button or you can't let those bindings run. The simplest
answer is to end your own binding with a "break" command.
bind .topl.picklist <ButtonRelease-1> {
set ListChoice [.topl.picklist curselection]
set request_type [lindex $DisplList [expr {$ListChoice + 1}]]
clearMessage
destroy .topl
break
}
That should really go in a proc, except for the break.
Are you really using the multiple-selection features of listbox?
If not, then why not use a popup menu?
--
Donald Arseneau as...@triumf.ca
jerry...@gmail.com
Take a peek at http://homepage.mac.com/levanj/TckTk I have some
examples
of how to use a popup menu to fill items in a Tktable row....
Jerry
jerry...@gmail.com
Lan
Wow! I'm overwhelmed by the generosity of ideas.
Last night I managed to master the tk_optionMenu widget enough to
conclude that, clever as the approach may be, behaviorially and
cosmetically it would likely be rejected by my windoze (oops! Prejudice
is slipping in) Windows users.
But I wanted to post back and say that I have so many suggestions that
it will take a while to digest them. Thanks to all, and please don't
think I've gone away ... I'm chewing what you've put on my plate.
Donald Arseneau
> Last night I managed to master the tk_optionMenu widget enough to
> conclude that, clever as the approach may be, behaviorially and
> cosmetically it would likely be rejected by my windoze (oops! Prejudice
> is slipping in) Windows users.
I'm not sure what reason tk_optionMenu would be rejected when a
listbox with [wm overrideredirect] would be acceptable. Do you
have some specifics?
--
Donald Arseneau as...@triumf.ca
suchenwi
Donald Arseneau schrieb:
> I'm not sure what reason tk_optionMenu would be rejected when a
> listbox with [wm overrideredirect] would be acceptable. Do you
> have some specifics?
>
pseudo-button at right, etc.
Joe English
It also has a suboptimal API: there's no callback option,
so the only way to tell when the user has selected something
is with a write trace on the linked variable; there's no
easy way to retrieve the index of the currently-selected
item, only the displayed label; and it has a variadic
constructor.
--Joe English
Lan
In all honesty, I anticipate rejection based on my experience with my
users, not because of any deficiency in the widget's functionality. But
the widget, in my experiments, was dynamic; i.e., instead of opening
like a combo box and waiting passively for a selection, it stayed open
while the left button was held down and grabbed whatever selection was
under the cursor when the button was released. Not "windows" enough by
half for these crybabi^H^H^H^H discerning windows developers.
Also, the widget had check buttons beside the selections. _Lozenge
shaped_ check buttons! Again, I would anticipate that my users wouldn't
be able to see past the unfamiliar, and I can't risk it because I only
get one first impression.
(Perhaps all this is configurable. I didn't see switches for it in the
docs I looked at, but the Tk never fails to amaze and delight me.)
It's kind of like selling a 2500 sq ft house and the prospective buyer
can't get past the tile color in the downstairs bathroom. I'm out on a
technical limb here using Postgres on Linux for the back end and Tcl/Tk
for the front. I have tepid management support, but if my users push
back for cosmetic reasons, the whole project could be scuttled and
we'll end up either doing this in MS SQL Server/Visual Basic (or --
here's a nightmare -- MS Access), or even worse, storing it all in
<gag> SAP. Which means the project would be DOA. Nobody stores anything
in SAP that they actually want to retrieve in a simple operation. SAP
is where data goes to die of loneliness. But upper management likes it.
I assume it's the pretty colors and well-dressed sales force.
Please don't take any rejection as personal. I have political and
psychological realities to deal with here. And I am testing and
assessing every suggestion I get.