B. Bogart wrote:
Hi Johannes,
I will not have a chance to look at your changes until I get back from vacation and start getting my new linux machine going.
well, happy holidays then.
so 100 seems to be sufficient anyhow) BUT i added additionally checks whether the max# has been exceeded; this keeps [popup] from segfaulting when you have more than 100 options
This sounds good to me. Are you doing some dynamic memory allocation to make this work?
yep
- using a mixture of user-defined and default values if you provide less
than 5 arguments (i thought that 5 args are a bit much to remember)
Any type checking to guess what arguments are what? 5 Arguments is indeed a lot. I'm actually hoping that one day PD will have a nice GUI API that includes the iemgui (or something similar) "inspector" window to change properties (like font, bg and fg colour etc..)
well not real type-checking; it is just assuming that you are giving the args in the correct order, but you don't have to remember all of them: so if you know what the 1st 2 args are (width height) but you cannot for the sake of yourself remember what comes next, you just give the 2 parameters and they will be used, and the others will get their default values (e.g. you really want a popup that is 300x100 pixes, but you don't know that the 3rd arg must be the color: now you get a 300x100 popup with default color; prior you got an all default popup)
- removed the "loadbang"-constraint (you can now add options and select
entries before the object has been drawn the 1st time)
Ah, how did you make this work? When I tried to send a loadbang to set a value it would always segfault. :( I could not figure out why and so added the funny bang thing, yes this is an ugly hack. Thanks a lot for fixing that, indeed beyond my debugging skill!
i have to admit it didn't segfault for me at all, i just got error messages concering .x45a310, which normally indicates that tcl-commands are sent to invisible gui-objects. at loadbang-time, the widget is not yet visible, but adding options via the "options"-message automatically draws; so the whole point was, that i had to check whether the widget is visible before sending any sys_vgui()-command (this should be done anyhow; probably it would make even more sense, if sys_vgui() could check this itself)
but i have some questions:
- why are there 2 inlets ? i noticed you uncommented the
class_addsymbol()-method, so it seems like there is some reason for not using the 1st inlet for both numeric and symbolic selection of elements.
This is a design idea, the left side is "float" space and the right side is "symbol" space. I thought two inlets made things more visual sense when there are two outlets. So no there is no technical reason here, aesthetic.
well, speaking of aesthetics, i use [popup] with sends/receives in gop-patches. the gop-patch is quite crowded, so i'd like to be able to control one [popup] with one single [send]. (and i don't want to add some administrative objects like [route] to split one incoming message to 2 outlets) using the cool empty-symbol trick for the second inlet does not allow me to send a message to the first inlet that controls the second one.
probably it would be good to get the best of both worlds: allow symbols on the 1st and on the 2nd inlet, with the same functionality.
- even more puzzling: why are there 2 outlets ?
for clarification, i don't have any problems with separate outlets for typfixed outlets (1 for numeric indices and 1 for symbolic names), but you are using the first outlet for 2 types (float vs. bang) so you somehow need a route to segregate those types. i would've suggested using either 1 outlet (with either ("bang" and "float" and "symbol") or ("bang" and "list")
As said above the bang is a hack and was not part of the original design. I don't want it! So your right that the idea was to have a separate float only and symbol only outlets.
yes, your aesthetic approach makes some sense.
since now the "loadbang" seems to work, could the "bang" output be removed ? (i find it rather annoying that everytime i switch console (this is: unhide the window), a bang is emitted.
yes yes yes, let me test to make sure it works on my machines.
fine
but i guess, this would break a lot of patches....
Hmmmm, maybe not so many. The suggest "route" usage would mean the lack of a bang would be ignored. What would be missing is the signal to set the value in some "loadbang" cases. Now is probably better to change this than later!
a good point
I think since so few people complained about the load-bang segfault that most people are not using popup with default values.
well, probably they either used your bang-hack or they didn't get any segfaults (like me).
Thanks for the contributions Johannes! :)
and i added a "disable"-message to disable user-input (but not effecting the control via inlets) and i added a "set"-message that does not output the values. and i fixed a bug that crashed pd when you had a [popup] in a gop-patch, and something was connected to the the popup's inlets (that was hard to discover)
probably more to come ;-)
mfg.adsr. IOhannes