On May 15, 2007, at 21:36 UTC, C. S. Wyatt wrote: > In the objected-oriented model of Delphi or, based on my little > experiments, Cocoa, every object is a descendant of "TObject" or > "NSObject" and every visual control is a child of TControl or Control.
Yes; in RB, every object is a descendant of Object and every visual control is a child of Control (and usually, of RectControl). > I can place, either in the IDE or via code, anything I can place on a > form within a cell in Delphi. Obviously, this can be really stupid > and cause headaches, but this is why I can put a table in a table or > any sort of static control in a drop-down list. It's all a matter of > the parent controls. In theory, you should be able to do that in RB too (at least insofar as controls within controls -- a listbox cell is not a control). It just doesn't happen to work, at least on OS X (there's a bug regarding this in the feedback system which has been Verified for quite a while, but I think it's a very hard thing to solve for various mundane reasons). > In RB, should I assume that the cells of a table are a collection of > EditFields? No. > Or, is it a control that is drawn independently and the > "edit field" is only superimposed while a cell is being edited? Yes. > (Talk about a kludge?) I disagree. Using a gazillion (or at least, several dozen) EditFields to make a list or grid would be a much worse kludge. You only need an EditField there when editing text; the rest of the time, a listbox cell is not an EditField, should not act like one, and does not need to be one. > I think the combo box is also rigged? I'm not sure what you mean by that. I'm pretty sure the combo box is a native control on most if not all platforms. > Goes back to why tab panels can't be placed on each other, controls > on tabs aren't "really" on the tabs.... etc. No, it really doesn't. The reason tab panels can't reliably be placed on each other has nothing to do with how things work under the hood, and is mostly to do with how they're defined in your project. Every control has one (count 'em!) TabPanelIndex property to indicate which tab or page it's on, if it's on a tab or page panel. You can see this if you export a window to XML, for example. This is a design decision that goes back to prehistoric times, and projects would break like mad if it were changed, but it causes confusion when you have nested panels. > This would explain why so many things done by programmers of RB are > canvas controls. I'm not following you there. But yes, a canvas is a great starting point for making any custom control. If only it would clip contained controls properly! Cheers, - Joe -- Joe Strout -- [EMAIL PROTECTED] Strout Custom Solutions _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
