#1008 [initbang] worked with GUI objs in 0.42 but not in 0.43

[Pierre-Olivier Boulant]

I have some abstractions which have an unauthorized/grid in a GOP. I change the colour at start up with a message triggered by [initbang]

If I create the abstraction in a new patch, it creates fine but the object is visible in the parent patch and will disappear after moving the abstraction in the parent patch.
But the parent patch will not load once the patch has been saved with such an abstraction.

console output for example patch1:

(Tcl) INVALID COMMAND NAME: invalid command name ".x675f00.c"
while executing
".x675f00.c delete 6990b8GRID"
("uplevel" body line 1)
invoked from within
"uplevel #0 $cmds_from_pd"

If I create a subpatch with no GOP (example 2) it loads with an other error message:

(Tcl) INVALID COMMAND NAME: invalid command name ".x699530.c"
while executing
".x699530.c delete 67b460GRID"
("uplevel" body line 7)
invoked from within
"uplevel #0 $cmds_from_pd"

The same patch but with a GOP starts fine (example 4) and a patch with no subpatch or abstraction works fine too.

Windows 7 (64bit), Pd extended final RC (2012 12 31) 32bit

[Pierre-Olivier Boulant]

example patches

[Hans-Christoph Steiner]

The problem here is [initbang], which sends its bang even before anything has been drawn. Switch to [loadbang] and it'll work. Using [initbang] means you're sending the [color ( message to the GUI part of the patch but it does not exist yet. That's what the Tcl error message is saying. .x699530 is the GUI ID for the patch, .x699530.c is that patch's Tk canvas, where everything is drawn. Tcl says "invalid command" because that Tk canvas has not been created yet.

I updated the [initbang] help patch to point this out.

[Pierre-Olivier Boulant]

Problem can also be worked around by inserting a [delay 10] between the [intibang] and the [color 10 10 10( message.

With 0.42.5 no error shown in the console, but the patch could start.
With 0.43.4 (2012 12 31) it just hangs.

[Hans-Christoph Steiner]

Hey IOhannes, any idea whether this points to a problem in 0.43/0.44 or not? Basically in 0.42.5, you can use [initbang] to send a [color( message to [grid] and it works. In 0.43, when the initbang is sent, the canvas hasn't been created yet. Using [loadbang] works fine.

[IOhannes m zmölnig]

i'd say that the problem is not with [initbang] (which doesn't make any assumptions about whether a patch is loaded or not), but really with the GUI-objects in question.

if the property of a GUI-object is set via a message, then thie GUI-object really must check whether it already has a valid canvas or not. if there is no canvas, then the object should store the values and apply them asap.

i don't think anything *guarantees* in [loadbang], that the canvas exists when it gets triggered. [loadbang] happens to fire after [initbang], so the chances are a bit higher that the canvas is already there.

adding a [delay] is a workaround, but also doesn't fix the underlying problem.