#202 Move non-essential and deprecated classes to OWLExt

[Vidar Hasfjord]

To simplify maintenance, it would be nice to move non-essential and deprecated classes to OWLExt, as to reduce the size and simplify the OWLNext core.

For example, TConfigFile and TMemComboBox, contributed by Yura Bidus, are additions to the OWL library. Since TConfigFile is not used in the core, and in effect duplicates and extends functionality in TProfile, we have decided it belongs in OWLExt. TMemComboBox depends on TConfigFile, so has been moved as well.

Note that CoolPrj depends on these classes, so it now depends on OWLExt. This requires an update in OWLMaker, to make sure libraries are built in the correct order.

See the discussion thread for [feature-requests:#201]:
https://sourceforge.net/p/owlnext/feature-requests/201/?limit=100#1f33

In addition, there are deprecated classes, such as TGauge (deprecated in 6.32), which we may want to retain in OWLExt, rather than completely remove.

[Vidar Hasfjord]

TConfigFile and TMemComboBox were moved to OWLExt in [r5905]. Note that Owlet removed TConfigFile and TMemComboBox long ago, so is not affected.

[Vidar Hasfjord]

I have now uploaded an new version of OWLMaker, build 5906, updated for the changes to the libraries. See [r5906].

This version also limits batch sizes to half the number of logical processors on the system, making the parallel build option more useful for large batches, which previously may have completely overloaded the system. See [r5903].

[Vidar Hasfjord]

I have reopened and broadened this ticket, since I think there are more we can and should move to OWLExt.

In particular, there are deprecated classes, such as TGauge, an old non-native OWL class. It has since been replaced by the class TProgressBar, encapsulating the native Windows common control (Progress Bar). See "Upgrading from OWL to OWLNext" and "FAQ | Why does TGauge no longer support native progress bars?".

I think it makes little sense to continue to maintain TGauge in the core, and it has unresolved issues (the implementation generates a TRect diagnostic, "TRect::TRect: Constructed from denormal values", in the Classes | Controls example). Code should ideally be rewritten to use TProgressBar, and for those who cannot or will not, we can retain it in OWLExt.

I also think it would be good to move Persistent Streams to OWLExt as well.

Let me known if you have views or objections.

[Vidar Hasfjord]

I have now moved TGauge to OWLExt [r5913]. Dependent classes owl::TSplashWindow and OwlExt::TGaugeGadget have been updated in [r5909] and [r5913], respectively. TSplashWindow now uses TProgressBar instead, while TGaugeGadget still uses the moved OwlExt::TGauge. Examples were rewritten to use TProgressBar and no longer use TGauge in [r5911].

Edit: The proxy header "owl/gauge.h" was added in [r6067]. If included, the precompiler will show a message about the move to OWLExt. If OWL5_COMPAT is defined, then "owlext/gauge.h" is included, and an alias for TGauge is added to the "owl" namespace. Otherwise, it is not defined. Using the alias may generate warnings about deprecation.

I will update our wiki to reflect the change.

Let me know if you have objections or suggestions.

[Vidar Hasfjord]

As mentioned in my comment to [feature-requests:#209], I think the Winsock encapsulation classes are horrible. Here are some of the problems I spotted just by a quick review of THostInfoManager:

• Code is not standard-compliant; in particular it uses illegal downcasting.
• Inconsistent error handling; no use of exceptions, mix of last-error and error return codes.
• The class design is horrible, with no well-defined purpose and class invariant.
  
  

THostInfoManager construction does more or less nothing. It creates a hidden notification window, which is only used by the GetHostInfoAsync member function overloads. Notably, any error in the creation of the notification window is just suppressed. Other than that, the constructor just initialises the members, but notably leaves the HostEntry member pointing to an uninitialised buffer (HostInfoBuffer). The latter is only initialised by a call to one of the overloads of GetHostInfoAsync, unless you pass a pointer to your own buffer. Also, the HostEntry pointer relies on an illegal downcast, as the buffer does not contain THostEntry instances, but rather instances of the base class hostent. Notably, the GetHostInfo member function overloads do not initialise the internal buffer, instead returning the host entry through an output parameter, leaving the HostEntry member still pointing to an uninitialised buffer. So by using the latter functions, your host info is not managed by this class at all, despite the appearance to do so, and the notification window stays unused. In fact, except for setting the member LastError (which is horrible error handling, by the way), the GetHostInfo overloads could just as well be free functions, not members. The same goes for other member functions, such as GetHostAddress, which both sets LastError, indirectly through the call to GetHostInfo, and returns an error code — which means the returned error may not be the LastError stored by the class, leading to error state inconsistency. Meanwhile, the HostEntryToAddress overloads are static members that return error codes, and hence do not affect LastError.

It is all pretty horrible!

A better design would remove the default constructor and initialise the managed host entry in constructor overloads, replacing the GetHostInfo and GetHostInfoAsync member functions, while using exceptions for all error handling. Functions not affecting the class state would all be made static, or better yet, removed from the class altogether.

In summary, the Winsock encapsulation classes are not part of the core GUI application functionality that the OWLNext core should be all about, in my view. There are better alternatives for networking, e.g. Boost ASIO, or even using Winsock directly rather than this kludge. Hence, I propose that we deprecate the Winsock encapsulation classes and move them to OwlExt.

Edit: I have now moved the Winsock classes to OWLExt [r6052].

[Vidar Hasfjord]

TGlyphButton has now been moved to OWLExt [r6065] and replaced by a proxy header [r6066] for backwards compatibility. While this class was in OWL 5, it has been deprecated and replaced by equivalent functionality for glyphs in TButton itself [feature-requests:#204], built upon button image support now in the Windows API.

If the proxy header is included, the precompiler will show a notice about the move to OWLExt. If OWL5_COMPAT is defined, then "owlext/glyphbtn.h" is included, and aliases for TGlyphButton and the accompanying helper class TBtnBitmap are added to the "owl" namespace. Otherwise, these are not defined. Using the aliases may generate warnings about deprecation.

Dependent classes TDrawItem and TBarDescr have also been moved [r6062][r6063]. Note that these dependent classes were not part of OWL 5, which is partly the reason for moving them, rather than removing the dependency.

The TDrawItem classes were authored by Yura Bidus, and there is a code comment that they are in an unfinished state. The classes have poor documentation and no demo code, and the implementation is not standard-compliant. In particular, ItemData2DrawItem, which was integrated within OWL's message handling of owner-drawn controls, does low-level and illegal pointer casting. To use these classes after their move to OWLExt, the user will have to intercept the relevant messages in the client code and implement a mechanism to forward them to the TDrawItem objects (e.g. a lookup table using the handle as a key). A TWindow mix-in with such message-forwarding functionality can be added to OWLExt later, if there is interest.

Likewise, TBarDescr is an extension by Yura Bidus. To use this class after its move to OWLExt, the user will have to incorporate it into the client code and overload the relevant member functions to perform the merging of the toolbar. A mix-in class with the latter functionality can be added to OWLExt later, if there is interest. If it should turn out that TBarDescr already has widespread use, we may look at bringing this functionality back into the core, while removing the dependency on TGlyphButton.

Note that these classes are actually not using TGlyphButton itself, but are using the helper class TBtnBitmap defined alongside it in "glyphbtn.h", simply to render bitmap backgrounds. So it should be relatively easy to remove the dependency, if we should so wish.

[Vidar Hasfjord]

The Persistent Streams library, which was deprecated and relegated to OWL5_COMPAT mode in OWLNext 7, has now been moved to OWLExt [r6072]. This means that, even in OWL5_COMPAT mode, the OWL classes are no longer derived from TStreamable and are hence no longer streamable to persistent streams (pstream) — except for tstring, TDate, TTime, TFileTime, TRect, TPoint(|L|F) and TSize, for which overloads of the streaming operators are still in place (now all declared in "include/owlext/objstrm.h" and implemented in "source/owlext/objstrm.cpp").

Example "pstream" has been updated and tested.