TcxSplitter - Use a transparent background in controls that reside in the design-time editor

Well DX wrote the TdxSplitter design-time editor. It is your baby to fix. That's why I say it looks unprofessional. It makes DX look unprofessional to have a dlg like this and kinda shows a lack of QA going on. I've always said… If the DX developers actually wrote some sort of app using their own controls, there woudl be far fewer issues being report by us end users. But we are cheap (free) labour and a sad trend in the industry that you write it, and someone else does your QA work.

Thank you for your reply. I cannot agree with you that we do not perform QA. We test (both via automatic tests and manually) each new build of our VCL products. In addition, we develop small demo applications using our controls to demonstrate new features. Recently we have started to work on "real-world" applications based on our controls (see the "Realtor World" demo for an example). This proofs that the quality of our controls is very important for us.
Anyway, it is not clear from your comment what exact behavior/appearance of the Splitter editor you consider unprofessional. Is it only a transparency issue? If so, I agree with you that it would be better to make controls transparent.

Well, I will leave you with these comments - no reply necesary… and not directly related to this thread, but QA in general
I've just spent the better part of 5 hours working with dxBarManagers and dxRibbons, etc. The list of problems with these controls is longer then my arm. I won't get bogged down in those details, but I can say that a real-life app will use form inheritance. And as we all know form-inheritance and collections do not go together well. To Dx's credit the BarManager code went through a large re-write a few years back to be more form-inheritence friendly. But it is still a nightmare when you have 5 levels of inheritance to deal with. In addition, the real world uses version control. And version-controlling DFMs and bars/ribbons is another area where the controls just seem to write piles of "stuff" - quasi-randomly changing values (left, top, width, height) etc. Throw in the dxLayout controls which override those properties and you are looking at a lot of "mods" which you didn't actually do.
Bottom line is that I restarted Delphi easily half a dozen times due to design-time crashes. So I maintain my position that DX could use more QA. Writing real-world apps is a good step and I am glad to hear that. But I always need to remind myself… am I working on the core logic of what our app does? Or am I trying to work out the nonces of a DX control not knowing if the problem is me, or a bug. Go review the MergeKind property in the help as an example. Exists for BarItems. No where to be found how dxRibbons merge even though there is a MergeKind defined for Tabs and TabGroups.
2-cents
-rs