Discussion of article "Custom Graphical Controls. Part 1: Creating a Simple Control"

 

New article Custom Graphical Controls. Part 1: Creating a Simple Control is published:

This article covers general principles of development of graphical controls. We are going to prepare tools for a quick and convenient work with graphical objects, analyze an example of creation of a simple control for entering text or numeric data as well as the ways of using it.

Author: Дмитрий

 
I wonder what's planned for part 2?
 
sergeev:

I wonder what is planned for the second part?
In the second part, a library of standard controls (more than 10 items: checkbox, combo box, scrollbars, list, radio buttons, etc.), in the third part - creation of forms with controls.
 

Will the ideology change? ...I really need it to change.

Maybe we should start with the third part - creating forms with your controls.

and then move on to the next part - to the inner workings of each element.

That is, first educate users on how the complex works as a whole, how the child element exchanges messages and events with the parent element, how the ideology works in general. This is important, because it is desirable to move from the general to the particular, - to the subtleties of each specific element.

And by the way - you should not emphasise on drawing, i.e. how each element is drawn (you can do it briefly, but you have all elements drawn by the Show function, so users will know where to look in each class to see the drawing block). Drawing is really nothing compared to the ideology of the whole process.

It would be better to show some ready examples of forms in which all elements are linked.

That is, on a ready example, to break down the specifics.

 
sergeev:

Will the ideology change? ...I really need it to change.

Maybe we should have started with the third part, the creation of the moulds.

and then gradually move on to the inner workings of each element.

What exactly is ideoligy?

A shape is basically nothing - x and y coordinates.

If you were to start with a form, what would you write there - "this is a form, and here you will add a control element, and here you will process its event...", but what kind of control element it is, what it represents - nobody knows.

If you make a form in the second part, while we have only one control element - it's not indicative and not beautiful.

 
Integer:

What exactly is it about ideoligy?

Form is essentially nothing - x and y coordinates.

Expanded on the answer just above.

You're right. That's the point, the form is nothing. What matters is the process of the exchange of events and the interaction of all the elements as a whole. And this can be explained only when you demonstrate the work of the system as a whole, not element by element.

 
Integer:

If you make a form in the second part, while we have only one control element - it is not indicative and not beautiful.
Do you already have the form and control class ready?
 
sergeev:

Expanded on the answer just above.

You are correct. That's the point, the form is nothing. The main thing is the process of event exchange and interaction of all elements as a whole.

There will be an OK and Cancel button on the form, data saving in case the terminal is restarted. There will be event handling, the ability to drag the form, minimise it.
 
sergeev:
Do you have the form and control class ready?

Quite ready. At first I did it without subwindows, now I'm redesigning everything to work in subwindows.

 
sergeev:

Will the ideology change? ...I really need it to change.

Maybe we should have started with the third part - creating forms with your controls.

and then move on to the next part - to the inner workings of each element.

That is, first educate users on how the complex works as a whole, how messages and events are exchanged between the child element and the parent element, how the ideology works in general. This is important, because it is desirable to move from the general to the particular, - to the subtleties of each specific element.

And by the way - the emphasis on rendering, i.e. how each element is drawn, should not be done. It is better to show some examples of how forms work and how all elements are connected. Drawing is really nothing compared to the ideology of the whole process.


Don't tell me, there are already enough examples of creating simple codes, but you can't create a successful hierarchy of classes or at least an easy-to-implement scheme of a universal, easily transformable product. Even standard classes from MQ often complicate the writing of programmes by laying down possibilities in advance.

 
Integer:
There will be an OK and Cancel button on the form, saving data in case the terminal is restarted. There will be event handling, the ability to drag the form, minimise.

OK. This is very good.

If you tell about high-level functions in the second part, the article components will be used faster.
I would still start with form + buttons (+ inputbox) and then only in the third part tell about specific control components - lists, menus, etc.

After all, the task is to teach how to write such controls. But as long as there is no form where to insert them, the article will not give such a spectacular and necessary effect.
Besides, as soon as you give Form+Button (I mean 3 kinds - radio, push, check) + EditBox already in the second article, the user will see the classes as a whole and will be able to create his own controls independently.