Very nice to see something like this.
I would be interested in making changes more to VB-like style (ie form.Caption = "something") instead of a function and such.
Also more of a suggestion - but you can use Option Tree for listboxes and such. Incredibly feature rich.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

Get/set for everything is horrible X_X
Having them as properties is more invigorating.

Yeah, but it makes more sense to keep the interface away from the data especially if you are in early stages of a library.

IIRC when you write a COM object in C++ (and I think the same applies to when you write them in VB) you have to use accessors in the interface you expose that the VB language then hides from the user when it makes those properties accessible.

Let the users access your data and somewhere down the line you might have to do something like check state before allowing access to that data, but as the data is "on show" your stuck

Ah yes, I was never suggesting letting users access data directly. No no no.
It's possible to "emulate" properties using some operators and templates. They act just like data members from the outside, but they are actually fully fledged functions.
That's similar to what I'm suggesting (I even developed a template for this kind of purpose).

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

thank you for your suggestion.
I tried to implement a generic property template, and its object is initialized in the init-list of a class, the property objects are always initilized with 'this' pointer, so compiler gives a warning that using 'this' in init-list, I don't like this warning, so I give up this implementation.

>>Option Tree for listboxes and such

All the widgets are own-draw, would you please implement an option tree? :-)

Nana C++ Library is a GUI framework that designed to be C++ style, cross-platform and easy-to-use.

thank you for your suggestion.
I tried to implement a generic property template, and its object is initialized in the init-list of a class, the property objects are always initilized with 'this' pointer, so compiler gives a warning that using 'this' in init-list, I don't like this warning, so I give up this implementation.

You can refer to "this" in the initialization list, but you cannot use it to either directly or indirectly reference members which have not yet been constructed. In other words, you can use "this" to access members of the base (if one exists) but not members of the class itself. At least, not members which are not yet constructed.

The conditions are sufficiently tricky, and compilers are sufficiently buggy, that a wise programmer would not use "this" in the init list. This is why the warning is there.

You can refer to "this" in the initialization list, but you cannot use it to either directly or indirectly reference members which have not yet been constructed. In other words, you can use "this" to access members of the base (if one exists) but not members of the class itself. At least, not members which are not yet constructed.

The conditions are sufficiently tricky, and compilers are sufficiently buggy, that a wise programmer would not use "this" in the init list. This is why the warning is there.

In other words, an proprety object should not use 'this' in the initialization list, because the object refered by this is under constrcution and the object is imcomplete. Although the property object just stores the 'this' while initializing, I gave up this implementation in logic/concept correct.

Nana C++ Library is a GUI framework that designed to be C++ style, cross-platform and easy-to-use.

Although the property object just stores the 'this' while initializing, I gave up this implementation in logic/concept correct.

I have met with similar designs, and the warning made me feel as you do. In the long run I think it is harmless in this situation, since the stored "this" will not be used until a call to a member, which can only happen after the object is fully constructed. You just have to be sure that the self-pointer is initialized in ALL constructors, including copy constructors -- which means you'll have to write a copy constructor explicitly.

yes, one property uses at least >=8 bytes, 4 bytes for 'this', 4(>=4) bytes for pointer of member function.

The function pointer can be passed via the template declaration instead to save some bytes...
4 bytes overhead is not much. It's typically what a smart pointer takes (or less).
I find it acceptable between functionality and overhead/size.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.