Short for Registered ID. Used in Dabo to uniquely identify a control on a given form.
RegIDs are different from names in that a name only needs to be unique among siblings, while a RegID must be unique on that form. This allow for unambiguously identifying a control without relying on complicated and unreliable containership pathing, such as
self.Form.pageframeMain.Page2.txtZipcode. Because of the special qualities of a RegID, if the control referenced in the prior sentence had a RegID of
ziptextbox, you could reference it by
RegIDs are not required for any control. However, once a value is assigned to a control, it cannot be changed. Attempting to assign a RegID that is already in use, or attempting to change an existing RegID will raise an AttributeError.
The following is an excerpt from an email discussion between Dennis Meulensteen (blue text) and Ed Leafe that explains the concept behind RegID and its practical use.
The line is:
self.dPanel.dGrid.Columns.WordWrap = True
I thought that, in order to reference the dGrid object, I had to reference it via its ancestors. Obviously this is not "quite" right....
So I'll come right out and ask. How do I reference objects like text boxes on a form correctly? I had hoped to discover this by myself but you beat me to it.
You can certainly reference objects through their containership hierarchy, using the dot-separated list of object names (i.e., the
Name property). Assuming in this case that
self is the form, you have to look to make sure that there is an object that is a child of the form whose
Name == "dPanel". If not, there's your problem (and that's what the error message indicates).
As you can imagine, this method of grabbing references is very fragile and error-prone. What happens if you move an object? What happens if you rename one of the containers? Those actions, while perfectly reasonable things to do during design, will break the reference. So Dabo uses a way to create references that are unique across any given form. This is based on the "Registration" design pattern, in which objects that need to communicate with other objects "register" themselves with the form. There is a property named RegID that exists just for this: it is empty by default, but if you need to get refer to that object anywhere within the form, set the
RegID to something unique and descriptive. When the form runs, the object will register itself with the form automatically, and after that you can then refer to it from anywhere using
form-dot-RegID. Example: if you set your grid's
RegID to be 'OrderGrid, the code to reference it would be
self.OrderGrid from within form methods, and
self.Form.OrderGrid from any other object within the form.
For example what I have in my search method on the base Form is: '
ddNaam is a drop down list. I can reference it from self but that's about it. I have tried everything I can think of but I still don't get it.
In that line of code,
ddNaam must be the value of the dropdown's
Name property, and it must be a direct child of the form for that code to work. The better solution would be to set its RegID to
ddNaam, and that would guarantee that your reference would work.
Name are completely different properties;
Name is required for all objects, and must be unique only among sibling controls.
RegID is completely optional, and if set it must be unique among all the controls on the form.