OWLNext: C++ Application Framework

Check out the new FolderSize example: https://sourceforge.net/p/owlnext/wiki/Examples/#foldersize It is also available for free download in the Microsoft Store: https://www.microsoft.com/store/apps/9P99P09FLLRF

These maintenance updates add support for Embarcadero RAD Studio/C++Builder 10.4 Sydney, and make some minor fixes as well. OWLNext 7.0.1 (changes | code | log) OWLNext 6.44.11 (changes | code | log) OWLNext 6.36.4 (changes | code | log) OWLNext Installation Guide

This update adds support for Embarcadero RAD Studio/C++Builder 10.4 Sydney [feature-requests:#160]. It allows you all to build and test the prereleases of the upcoming refreshes of OWLNext, which will have support for the latest Embarcadero toolset ... [More] , as well as various fixes. Releases are upcoming soon — so please test! OWLNext 7.0.1 Prerelease (changes | code | log) OWLNext 6.44.11 Prerelease (changes | code | log) OWLNext 6.36.4 Prerelease (changes | code | log) OWLNext Installation Guide This OWLMaker update also fixes an issue where the "Toolset location is initialized with garbage" [bugs:#465]. For more details on the changes, see the code log. [Less]

This update adds support for Embarcadero RAD Studio/C++Builder 10.4 Sydney [feature-requests:#160]. It allows you all to build and test the prereleases of the upcoming refreshes of OWLNext, which will have support for the latest Embarcadero toolset ... [More] , as well as various fixes. Releases are upcoming soon — so please test! OWLNext 7.0.1 Prerelease (changes | code | log) OWLNext 6.44.11 Prerelease (changes | code | log) OWLNext 6.36.4 Prerelease (changes | code | log) OWLNext Installation Guide This OWLMaker update also fixes an issue where the "Toolset location is initialized with garbage" [bugs:#465]. For more details on the changes, see the code log. [Less]

Today, after being baked on the trunk for quite a few years, OWLNext 7.0 was released as the first in a new development series based on C++17. Series 7 aims to be a comprehensive modernisation of OWLNext, influenced by work on Owlet, an experimental ... [More] subset of OWLNext, allowing the user to write code in a modern C++ style, while fearlessly eliminating ugly code, cumbersome constructs and brittle idioms. Support for older compilers and Windows XP is dropped. With the release of version 7.0 as the new development series, 6.44 now enters maintainance mode, as a stable backwards compatible version with support for older compilers. No further features are planned for the 6.40 series, except for any eventual bug fixes and compiler support. OWLNext 7.0 (changes | code) Online OWLNext 7.0 Documentation Installation Guide [Less]

Owlet has gone macro-free! Well, for response tables, at least. You will now no longer find any class using OWL_DECLARE_RESPONSE_TABLE within the library. Instead, classes will simply override TEventHandler::GetHandlerFunction (formerly known as ... [More] Find), which was all this macro did anyway (after simplifications — OWL 5 has some extra cruft): // /// Searches response table and bases. // auto GetHandlerFunction(const TEvent&) -> TDispatchDelegate override; The macro is still available for client code, but it will probably soon be relegated to a compatibility mode. Similarly, the macro OWL_DEFINE_RESPONSE_TABLE has been replaced simply by the definition of GetHandlerFunction. For example, here you have the definition for TListBoxView: auto TListBoxView::GetHandlerFunction(const TEvent& event) -> TDispatchDelegate { using T = TListBoxView; return SearchEntries<T, TListBox>(*this, event, { MakeCommandEntry<&T::CmEditUndo>(CM_EDITUNDO), MakeCommandEntry<&T::CmEditCut>(CM_EDITCUT), MakeCommandEntry<&T::CmEditCopy>(CM_EDITCOPY), MakeCommandEntry<&T::CmEditPaste>(CM_EDITPASTE), MakeCommandEntry<&T::CmEditClear>(CM_EDITCLEAR), MakeCommandEntry<&T::CmEditDelete>(CM_EDITDELETE), MakeCommandEntry<&T::CmEditAdd>(CM_EDITADD), MakeCommandEntry<&T::CmEditItem>(CM_EDITEDIT), MakeMessageEntry<WM_GETDLGCODE, &T::EvGetDlgCode>(), MakeCommandNotificationAtChildEntry<LBN_DBLCLK, &T::CmEditItem>(), MakeCommandNotificationAtChildEntry<LBN_SELCHANGE, &T::CmSelChange>(), MakeViewNotificationEntry<vnDocClosed, &T::VnDocClosed>(), MakeViewNotificationEntry<vnIsWindow, &T::VnIsWindow>(), MakeViewNotificationEntry<vnIsDirty, &T::VnIsDirty>(), MakeViewNotificationEntry<vnCommit, &T::VnCommit>(), MakeViewNotificationEntry<vnRevert, &T::VnRevert>(), }); } All pretty straight forward, right? Except for some brevity, nothing is lost in the translation (see [r4914] to compare before and after). On the upside, you can easily customise this code, and you can step through it line by line in the debugger. It may seem inefficient to create the table in every call, but the compiler should be able to optimise this, as every entry factory function here is declared constexpr and hence evaluable at compile-time. That said, there is one built-in factory function, MakeRegisteredMessageEntry, not used here, which is not constexpr, and for which the table should be made a static array instead, to ensure it is created only once. For example, see TEditSearch::GetHandlerFunction: auto TEditSearch::Find(const TEvent& event) -> TDispatchDelegate { using T = TEditSearch; static const auto table = std::array { MakeCommandEntry<&T::CmEditFind>(CM_EDITFIND), MakeCommandEnableEntry<&T::CeEditFindReplace>(CM_EDITFIND), MakeCommandEntry<&T::CmEditReplace>(CM_EDITREPLACE), MakeCommandEnableEntry<&T::CeEditFindReplace>(CM_EDITREPLACE), MakeCommandEntry<&T::CmEditFindNext>(CM_EDITFINDNEXT), MakeCommandEnableEntry<&T::CeEditFindNext>(CM_EDITFINDNEXT), MakeRegisteredMessageEntry<&T::EvFindMsg>(FINDMSGSTRING), }; return SearchEntries<TEditSearch, TEdit>(*this, event, table); } For more about the response table macros and their elimination, read Response tables without macros in our Knowledge Base. The knowedge base archive of articles on OWLNext innards and related topics is well worth checking out, if you have not already done so. From time to time new wisdom is added to the archive, so make sure to check back occasionally. PS. The Razee game (examples/razee) has gone macro-free as well. [Less]

This update fixes issues with TRegexp, registry classes and configuration file classes. It also adds a brand new example demonstrating how to use CrystalReports.NET from OWLNext. OWLNext 6.44.10 (changes | code) Installation Guide

This update fixes a problem with the update function. So, ironically, you may have to download this update manually. The update also implements [feature-requests:#55] "OWLMaker should look for per-user OWLROOT setting". If you set an environment ... [More] variable named OWLROOT to point to your OWLNext installation, OWLMaker will give you a button "Locate" on the start page of the OWLMaker Wizard. Pressing this button will enter the value of the variable into the field for the OWLNext root location. Previously, this worked only if OWLROOT was a system environment variable, but it now also works if OWLROOT is a user environment variable. For more details on the changes, see the code log. [Less]

OWLMaker now includes a new command: Tools | Download source code. This command simplifies the setup of OWLNext. You can select among the latest available releases in our Files download area, and OWLMaker will download and unpack the selected ... [More] archive. You can also select to download documentation at the same time. For further convenience, the same functionality is available from a new button "Download source code" on the start page of the OWLMaker Wizard. After source code download, the path of the selected download destination folder is automatically filled into the "OWLNext root location" field. For all the details of the changes made in this version, see the Code Log. [Less]

To round off the year, here is a bugfix update. OWLNext 6.44.9 (changes | code) Installation Guide