Python and the GUI Separator

Cairyn

Hello, I found a dubious detail in the function GeDialog.AddSeparatorH()...

The Python header shows the parameter list as
GeDialog.AddSeparatorH(self, inith, flags=BFH_FIT)
But if you set inith to anything, the height of the separator stays the same... no effect at all. (Nevertheless it's a mandatory parameter.)
In the parameter list below, that parameter suddenly becomes
initw (int) – Initial width.
No inith is listed... but initw is not accepted as parameter.

So I looked at the C++ documentation... and find initw:
initw The initial width. Use SizePixChr() to set this value.

The Python doc for AddSeparatorV contains an initv in both header and parameter list (I didn't check whether it has any effect) but an inith in the C++ docs.

So, what is correct? And if inith is the only accepted parameter, why doesn't it do anything?

(And not to be picky, but the Python doc screenshot snippet for AddSeparatorV shows the horizontal separator again. )

Manuel

hi,

i've openned a bug report for that and fixed it. It will be available in a next update of Cinema4D.

By the way, the python function was calling AddSeparatorH. (even for sub dialog)
I've modified the python documentation so it will reflect the c++ documentation.

You should add some flags in order to have an expected result.

this is the result of the following code:

        self.AddSeparatorV(inith=30)
        self.AddSeparatorV(inith=150, flags=c4d.BFH_LEFT)

I'm not sure if that make sense to have a vertical separation that still take the whole space in width. (because there's no flag.
Also be careful at how flags are set for the group that receive those separators.

Cheers,
Manuel

Cairyn

Ah, I see, inith in AddSeparatorH is actually a width value, and since flags defaults to BFH_FIT, you cannot see any effect since the control adapts the full width. And since the function doesn't accept an initw or initv parameter, there is no height control at all.

And since AddSeparatorV is calling up a horizontal line, I can't expect correct results anyway.

Thanks for the info.
(btw, there are multiple copy&paste errors in the GeDialog doc, shall I send you some? Not serious enough for a full bug report, but...)

Manuel

@Cairyn said in Python and the GUI Separator:

btw, there are multiple copy&paste errors in the GeDialog doc, shall I send you some? Not serious enough for a full bug report, but.

Of course, opportunity to have a better documentation is more than welcome.
that allow us to track things and add them in our changelogs.

Cheers,
Manuel

Cairyn

@m_magalhaes said in Python and the GUI Separator:

Of course, opportunity to have a better documentation is more than welcome.
that allow us to track things and add them in our changelogs.

okay... (everything here is for the Python doc page for GeDialog, unless specified differently)

The first one would be a line that I believe to be erroneous but maybe there's a secret functionality behind it that I don't get: Both GeDialog.AddRadioButton and GeDialog.AddRadioText have the note Used with radio groups created with AddRadioGroup(). However, there is no way to connect these controls with a radio group. Radio groups only accept AddChild entries, and AddChild cannot refer another control as subid. (id can be a C4DGadget but subid can not.) The calls AddRadioButton/Text do not allow to specify a radio group as parent. So, unless there is an undocumented trick, this note may be wrong.
(To use RadioButton and RadioText, I handle the clicks myself in the Command method, and deselect the complementary controls.)
The screenshot under AddColorField belongs actually to AddColorChooser.
Not an error, but it would be nice to mention under GeDialog.AddDlgGroup that DLG_OK and DLG_CANCEL are not just the flags for type, but also serve as IDs for the buttons that can be evaluated in the Command method. I think it's unusual to have bitset flags at the same time as result integers (even in C4D: the MessageDialog has GEMB_xxx values as boole-combineable flags, but separate GEMB_R_xxx constants as results) so it bears mentioning.
GeDialog.AddSlider tells us Adds a slider with an editable number field to the layout. which is apparently copied from AddEditSlider, as AddSlider does not have a number field.
GeDialog.AddChildren - what's supposed to be in the BaseContainer bc? I originally assumed you could use it like this:

self.AddRadioGroup(ID_RADIO_MAIN, flags = c4d.BFH_LEFT, columns = 1)
r1 = self.AddRadioText(id=ID_RADIO_4, flags=c4d.BFH_SCALEFIT, name="A radio text")
r2 = self.AddRadioText(id=ID_RADIO_5, flags=c4d.BFH_SCALEFIT, name="Radio text 2")
r3 = self.AddRadioText(id=ID_RADIO_6, flags=c4d.BFH_SCALEFIT, name="RT3")
bc = c4d.BaseContainer()
bc.SetData(ID_RADIO_4, r1)
bc.SetData(ID_RADIO_5, r2)
bc.SetData(ID_RADIO_6, r3)
self.AddChildren(ID_RADIO_MAIN, bc)

but SetData raises an error. As a BaseContainer is a C++ structure and r1 is a Python data, I come to doubt that would even be possible, so perhaps AddChildren is limited to ID / string combinations, which actually do work:

self.AddRadioGroup(ID_RADIO_MAIN, flags = c4d.BFH_LEFT, columns = 1)
bc = c4d.BaseContainer()
bc.SetData(ID_RADIO_4, "Text1")
bc.SetData(ID_RADIO_5, "Text2")
bc.SetData(ID_RADIO_6, "Text3")
self.AddChildren(ID_RADIO_MAIN, bc)

May be useful to document that explicitly. The C++ page for the same command also says nothing on the subject.

GeDialog.GroupBegin What is the difference between BFV_GRIDGROUP_EQUALCOLS - Each column has the same width and BFV_CMD_EQUALCOLUMNS Columns have equal width ? I couldn't get the second one to work. Deprecated?

Okay, that's what I noticed while working through the GeDialog page. I skipped a lot so there may be other open issues.

Manuel

hi,

Just to keep you inform. This will be updated as soon as possible but i didn't got time to focus on that.
It still on my desk.

Cheers,
Manuel

Manuel

Hi,

Never say never!!

I've fixed the issue you pointed out.

About the AddChildren, I've modified the documentation so only ID are working. The parameter expected for that function is a GadgetPtr and not a wasn't a C4DGadget. GadgetPtr isn't available in Python.

BFV_CMD_EQUALCOLUMNS seems only used for CommandPaletteArea. You can define the palette direction vertical or horizontal. So, the symbol exists but can be ignore. (Its ID isn't the same than BFV_GRIDGROUP_EQUALCOLS)

Cheers,
Manuel

Cairyn

Good to hear, thanks!