Cabbage Logo
Back to Cabbage Site

Question about the usage of the identifier "parent"

#1

So, Rory, I’ve been working with my “creator” library to build a synth, and out of curiousity I copied and pasted the “widget” code it generates directly into the cabbage section, and ran the code. Now considering that this is a complex interface (using lots of plants), the documentation for how the “parent” identifier is used states:

It should only be used when creating widgets dynamically using the cabbageCreate opcode.

(Sorry, I don’t know how to do that as a link…)

But my question is that when I run my code, everything appears to operate correctly, making all the correct plant objects visible as needed. I attached the latest version that I am talking about. It only has one include file to handle the code needed to make all the plants hidden/visible. Otherwise, this is directly output from my library. Do note that the widgets that call a ‘parent’ identifier are not even grouped together. I did make one edit to remove an ‘schedulek’ call, but that instrument is defined in another include. The file not labeled as smaller is 2100 x 700 for a large screen (like the one I’ve got), and the other is 1400 x 700, might be bigger than other can use still.

Archive.zip (12.8 KB)

So, is this kosher with cabbage? A Happy accident? Something to be avoided?

Just as a operating starting point, under the drone section, selecting one of the top row buttons selects one of the drone instances. The “huge” combobox is used to select the input for this drone. The row of buttons below that will select the envelope plant for that operator, and the bottom combobox will allow the selection of the plant for each of the different types. Also, note that in the lower right corner of the large window, as you roll over a widget, all of them will display their channel name, and some will display their usage.

Mike

#2

This looks quite strange when I open it? Lots of empty space and widgets on top of each other. Is that what I should see? Also, just curious, what version of Cabbage are you using?

:+1:

Does this not contradict the earlier statement about everything working fine?

p.s. I can’t get any plant groups to appear, maybe that’s the issue?

#3

Yeah, I started building this a couple days ago, so I’m not near completion. I was just curious about my use of the ‘parent’ identifier in the Cabbage code section, and not in a call to cabbageCreate.

But anyway… if you start the ‘csd’ file, and run your mouse over the combobox just below the ‘0’, ‘1’, ‘2’, and ‘3’ drone select buttons, the labels just under the “System” label (on the right side, near the bottom) should be changing. When it starts up, the big combobox should display “dr3_input” as your mouse rolls over it. If you click on the ‘0’ button, and roll over the big combobox again, it should now display “dr0_input”. If you click on the numbered buttons sucessively, the combobox should change accordingly. If this is do what I am describing, then yes, it is working properly and changing the plants as necessary.

Also, if you select any of the ‘e0’,‘e1’, etc, buttons just below the big combobox box, the displayed channel names for each widget should be changing the labels under “System”. Try rolling over the other labels, the channel name display on the right should be changing as well.

If those labels are not changing for you, then I guess it isn’t working as I thought.

I am using Cabbage 2.9. I do have some older versions of the development builds, I just tried 2.8.162, and it is working properly for me.

So, that brings me back to my original question. The manual says that the ‘parent’ identifier should only be used in conjunction with ‘cabbageCreate’. But with my code working for me (and hopefully now, you), with using ‘parent’ in the cabbage code section, it kind of either contradicts what the manual is saying, and it is fully functional and I can freely use ‘parent’ in the cabbage code section. Or it means that I should not be using it, despite it appearing to work.

#4

Thanks for the clarification @mjmogo I see what you mean now. I can’t recall fully why I wrote that in the docs, but it was most likely because I found an edge case that caused a problem. So long as you define the parent before you try to assign a widget to it then I guess it should be fine.