SOME CLARIFICATIONS... (PART II)
Posted: Sun Mar 28, 2010 1:05 am
The second part of this document will be devoted to the (IMHO) most outstanding cases of outdated technologies, low level techniques exposed to the users and design inconsistencies.
11. "IMAGELIST control - support for resources from bitmap's list".
ImageList is an image storage facility and its use is required for most controls that works with images.
HMG uses Imagelists for Button, CheckButton, ComboBox, Grid, Tab and Tree controls.
HMG requires from the user that only specify the image file or resource name to associate it with a control, HIDING complexities associated with such operations (ie: ImageList manipulation).
IMHO, there is no point on 'expose' a low-level component as an Imagelist to the user. That is not consistent with HMG overall design goals nor xBase spirit at all.
12. "MDI support"
MDI stands for "Multiple Document Interface".
MDI is a 'relic' from the Windows 3.x era.
MDI is usually confusing for the users and most of the modern software AVOID ITS USE.
This is the official Microsoft recommendation about MDI:
"MDI is an application-oriented model. Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, many applications are switching to a document-oriented model. Therefore, you may want to consider other models for your user interface..."
You can check it at: http://msdn.microsoft.com/en-us/library ... S.85).aspx
Considering the difficulties that MDI presents to the users, I've avoided to adding to HMG. Instead I've created SplitBox control (based on REBAR Windows native control).
14. "TSBrowse library support"
This is another case of a new control with the same purpose of an existing one with new functionality added.
The main problem with this control is that it uses Clipper's standard OOP style instead HMG's one, so, its handling is not consistent with the rest of the HMG's GUI objects.
15. "BTNTEXTBOX control - extended TEXTBOX control with inserted button."
IMHO, creating a new control as a combination of two existing ones (TextBox and Button) only adds complexity to the library, driving to a steep learning curve.
16. "TOOLBAREX control - toolbar with a clauses <...> IMAGELIST, HOTIMAGELIST <...>"
Another duplicated control with some new added functionality. It requires access to the Imagelist low-level component.
17. "DEFINE FONT <...> RELEASE FONT <...>"
This case is similar to the ImageList one.
HMG uses font objects for almost all controls, HIDING complexities associated with its operation, so the user must only specify font features (as control properties) without to deal with font object creating, bounding, releasing, etc.
Exposing a low level object (as font) to the user is (IMHO) clearly inconsistent with HMG overall design goals.
18. "SET EVENTS FUNCTION TO <funcname> - define the user's events handling function"
Exposes low-level operating system internals.
19. "GETBOX control - Windows implementation of Harbour`s GET Class"
GETBOX is basically a TEXTBOX.
IMHO, the right path to achieve @...GET compatibility without creating a new control similar to an existent one, is to add the required new properties to the TEXTBOX control.
Such new (optional) properties (VALID, PICTURE, RANGE, etc.) could be used for whose wanting full Clipper compatibility for data entry.
20. All the other things...
Regarding the other things not described here, you'll find some more minor problems, but some interesting additions too.
I've added such 'interesting' ones to my TODO list
To be continued...
11. "IMAGELIST control - support for resources from bitmap's list".
ImageList is an image storage facility and its use is required for most controls that works with images.
HMG uses Imagelists for Button, CheckButton, ComboBox, Grid, Tab and Tree controls.
HMG requires from the user that only specify the image file or resource name to associate it with a control, HIDING complexities associated with such operations (ie: ImageList manipulation).
IMHO, there is no point on 'expose' a low-level component as an Imagelist to the user. That is not consistent with HMG overall design goals nor xBase spirit at all.
12. "MDI support"
MDI stands for "Multiple Document Interface".
MDI is a 'relic' from the Windows 3.x era.
MDI is usually confusing for the users and most of the modern software AVOID ITS USE.
This is the official Microsoft recommendation about MDI:
"MDI is an application-oriented model. Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, many applications are switching to a document-oriented model. Therefore, you may want to consider other models for your user interface..."
You can check it at: http://msdn.microsoft.com/en-us/library ... S.85).aspx
Considering the difficulties that MDI presents to the users, I've avoided to adding to HMG. Instead I've created SplitBox control (based on REBAR Windows native control).
14. "TSBrowse library support"
This is another case of a new control with the same purpose of an existing one with new functionality added.
The main problem with this control is that it uses Clipper's standard OOP style instead HMG's one, so, its handling is not consistent with the rest of the HMG's GUI objects.
15. "BTNTEXTBOX control - extended TEXTBOX control with inserted button."
IMHO, creating a new control as a combination of two existing ones (TextBox and Button) only adds complexity to the library, driving to a steep learning curve.
16. "TOOLBAREX control - toolbar with a clauses <...> IMAGELIST, HOTIMAGELIST <...>"
Another duplicated control with some new added functionality. It requires access to the Imagelist low-level component.
17. "DEFINE FONT <...> RELEASE FONT <...>"
This case is similar to the ImageList one.
HMG uses font objects for almost all controls, HIDING complexities associated with its operation, so the user must only specify font features (as control properties) without to deal with font object creating, bounding, releasing, etc.
Exposing a low level object (as font) to the user is (IMHO) clearly inconsistent with HMG overall design goals.
18. "SET EVENTS FUNCTION TO <funcname> - define the user's events handling function"
Exposes low-level operating system internals.
19. "GETBOX control - Windows implementation of Harbour`s GET Class"
GETBOX is basically a TEXTBOX.
IMHO, the right path to achieve @...GET compatibility without creating a new control similar to an existent one, is to add the required new properties to the TEXTBOX control.
Such new (optional) properties (VALID, PICTURE, RANGE, etc.) could be used for whose wanting full Clipper compatibility for data entry.
20. All the other things...
Regarding the other things not described here, you'll find some more minor problems, but some interesting additions too.
I've added such 'interesting' ones to my TODO list
To be continued...