Well that’s the point right there. Perhaps I do understand. When creating the layout of my software it’s nice to be able to “see” the layout without having to run it. Otherwise we end up having to write down co-ordinates. Fine, I’ve done it, and it has to be done at run-time sometimes.
Surely seeing what you’re creating in the actual IDE is of much benefit.
I agree the layout editor is of much help. That is why I suggested the second approach.
When you position controls by coordinates, they do not become child of the underlying control, and you don’t need to do anything at run time.
Thanks Michel, positioning controls via co-ordinates in the IDE is one thing - positioning via code at run-time is another.
I do understand it. I’ve used various phototypesetting machines since they first came on the market. In the early days you had no visual indication except for text (wording) and input via a thin text screen that has no undo if you pressed enter. The first that I can remember was a compugraphic, I learned how to read paper tape.
Then came more sophisticated systems. You had a window where you typed in co-ordinates of objects, lines and text (no images). and a “rough” rendering was shown on another screen. Fascinating as that may be, I don’t expect to have to do that sort of coding in 2017 just for the “look”. bla, bla, bla.
The worst (non-coding) issues I’m having is to do with flashing labels. I will have to, in the end, code the labels/text within a canvas using stringshape.
[quote=328140:@Steve Kelepouris]
There must be something basic about layering controls that I must be missing. Isn’t it used and essential in gaming type programs, ie. canvas within canvas within canvas that may include other controls? [/quote]
Generally no.
They draw everything - like one giant canvas that you write code to draw everything and possibly even the controls.
For instance IN The IDE the layout editor IS just one giant canvas that we draw everything - it just looks like a real live window.
There are lots of places in the IDe where it LOOKS like a control but really is just a canvas that we take care of drawing everything into.
Steve, I don’t get your statement. You don’t have to place things in code. You simply have to remove the parent property.
Precisely because I cannot modify the parent property in iOS, I am reduced to move them in place in the Open event. This is not fun indeed.
Seems to me you deeply misunderstand the advantages of the parent/children feature, for instance to create in an instant a portion of interface by stacking controls on a canvas, which will make them move and become visible with it.
I understand you imagine controls as pieces of cardboard that do not interact between themselves. That is unfortunately not the way it work.
Since you have a background in graphics, I believe you should be able to understand how to draw controls and create an entire interface on a single canvas. With that method, very little flicker, and you are entirely in control. But there is a learning curve.
In the case of your OP, though, the entire picture can be made into a canvas, so you have full control of how it will look, and no pesky one pixel in the corners.
[quote=328166:@Norman Palardy]Generally no.
They draw everything - like one giant canvas that you write code to draw everything and possibly even the controls.
For instance IN The IDE the layout editor IS just one giant canvas that we draw everything - it just looks like a real live window.
There are lots of places in the IDe where it LOOKS like a control but really is just a canvas that we take care of drawing everything into.[/quote]
[quote=328204:@Michel Bujardet]Steve, I don’t get your statement. You don’t have to place things in code. You simply have to remove the parent property.
Precisely because I cannot modify the parent property in iOS, I am reduced to move them in place in the Open event. This is not fun indeed.
Seems to me you deeply misunderstand the advantages of the parent/children feature, for instance to create in an instant a portion of interface by stacking controls on a canvas, which will make them move and become visible with it.
I understand you imagine controls as pieces of cardboard that do not interact between themselves. That is unfortunately not the way it work.
Since you have a background in graphics, I believe you should be able to understand how to draw controls and create an entire interface on a single canvas. With that method, very little flicker, and you are entirely in control. But there is a learning curve.
In the case of your OP, though, the entire picture can be made into a canvas, so you have full control of how it will look, and no pesky one pixel in the corners.[/quote]
Much appreciated Norman and Michel. But I still don’t get it. You may well be pulling your hair out at that statement, but I must be missing some really crucial point here.
At the moment my software is working fine. The graphics and the “look” is almost perfect. Perhaps in the end, I can draw pixel points over the offending popup menus using the main window coordinates. The main window is a fixed size, so that shouldn’t be an issue.
Apart from tying me in a chair, with restraints on my head, forcing me to look at something, then slapping me across the face repeatedly (and very hard), saying “just look at it steve”, “look”, “look”, “look”!!!, well,… I fail to understand.
Essentially, at run time, what you see as controls is just drawings on the screen. Your issue above would not exist if instead of using controls, you drew these elements as one graphic in a canvas, and used the mouseDown/MouseUp events to respond to user clicks.
Here is a very quick example of just the same thing as what you show, without the pesky white dots (thanks Photoshop), done with only one control : canvas.
Buttons&canvas.zip
I did animate one button : Serial Port. That will show you how to do it with others.
This should tickle your graphic side : instead of shuffling controls, you can literally draw the UI to your heart’s content in Photoshop or other graphic tool without fearing side effects like unwanted child parent relationship. Added bonus (some will say issue but color and taste is a personal choice), the UI will be identical across platforms and system versions.
As you can see, no need to fuss with countless controls and stacking stuff. Incidentally, this will flicker a lot less, especially if you set the canvas to double buffering under Windows.
[quote=328760:@Steve Kelepouris]Much appreciated Norman and Michel. But I still don’t get it. You may well be pulling your hair out at that statement, but I must be missing some really crucial point here.
At the moment my software is working fine. The graphics and the “look” is almost perfect. Perhaps in the end, I can draw pixel points over the offending popup menus using the main window coordinates. The main window is a fixed size, so that shouldn’t be an issue.
[/quote]
Thats the “crucial point” you’re missing
You cant simply plop a pixel over those
The UI doesn’t composite together that way
To remedy this, you need to render the control yourself using the BS_OWNERDRAW button style, this will allow you to listen for the WM_CTLCOLORBTN message and ultimately control the background colour of the button, which is what those corner pixels are.
I suspect this is a little overkill for getting 4 pixels coloured correctly, personally I would just drop the bevel, however my suggestion would be to compromise on the dark bevel, try an inset bevel and chose a lighter fill, thus mitigating the difference between the corner pixels and the background while maintaining the “grouping” intention of the bevel.
Look above, the OP as a graphist already rebuffed my same suggestion (white background) as not adequate, since it negates the embossing effect required by his design.
I know, but if you hit a rock hard enough, it breaks 
After all, beauty is in the eye of the beholder.
Should we tell him that is X border is 2 pixels bigger than his Y border and the spacing between the Connect and COM 3 isnt the same? Shhh
Julian, you’re not nice. He could lose sleep over it 
Thanks guys - I deserved that, and it’s very much appreciated, I had a good laugh 
@Julian
I guess we have different views on adages. My alternative is “If you hit a rock hard enough, perhaps whatever you’re hitting it with, could break first” 
Above is the entire panel. The spacing between Connect and COM3 actually has a purpose.
But there is “Method to that madness”. Everything has a purpose, otherwise it shouldn’t be there. That panel represents a quite complicated process. The blue arrow next to CHECK is similar to the “follow the bouncing ball” step by step scenario. The current status panel also gives important information.
I think I mentioned above that (apart from the code) the UI is very important. When things don’t line up, or appear to be disjointed, our eyes can easily pick this up. It makes the UI look messy and disorganised and could potentially make the user not want to use your software. Of course there are compromises have to be made.
There was a post recently where someone asked what is standard spacing between labels and controls. There is no particular standard, consistency is the key, and alignment of objects.
Anyway, I was actually hoping to win this years “Xojo’s Best User Interface Award”, but sadly those little annoying white dots will put an end to that dream. :’(
And Yes Michel, I do lose sleep over it - I guess there’s always next year
BTW. If you were faced with the panel above, what do you think you should do next, to proceed?
From what I see, this entire interface can be drawn and made active from a single canvas, based on the same principle as the little proof of concept project I posted.
That entire panel IS within a canvas, and other canvases and controls reside with that - it all works fine. I accept the white dots cannot be removed without re-creating the whole thing in photoshop. I’m pragmatic enough to accept that, that is the way it is.
I already know that I could draw the whole thing in Photoshop or Illustrator, why do that when you can simply place controls in the IDE itself?
So, given the sample panel above, what do you think the user would do next?
Except you get those pesky white dots, and controls becoming parents.
I was just trying to help. Now you do as you please. Good luck.
Michel, I know you were trying to help. I very much appreciate and value your opinions and advice. I did download the example that you posted above and I can see how that could work. However, I’ve decided to stick with my way regardless of it’s limitations.
Thanks.
I know I am coming late to this conversation but I have created a button control that you can drop on your container/canvas/window that is a simple button that allows a drop-down list and selection.
It is called dropButton and is inside the attached project file:
DropButton
It can be extended to dynamically populate the drop-down list, not done as yet, but will be extended for this later. At this time it is just here to help out.
Simon.
I posted an example not only for Steve, who after all already has his project finished (except for four pesky pixels ! ), but for whomever is in search of ways out of complex and flickery assemblies of stacked controls.