RGR: examples/replaceplus: UNICODE build mode fails [r8772].
CHG: ReplacePlus example: Optimize the population of the results listbox control.
CHG: ReplacePlus example: Display the number of replacements per file in the results list.
CHG: ReplacePlus examples: Attempts to calculate the minimum window size from the dialog template.
@jogybl wrote: Had a better idea Very nice!
CHG: ReplacePlus example: Preserve dialog position and size. See comment in [feature-requests:#217].
CHG: ReplacePlus example: Dialog adjustments.
align the horizontal separator line to the bottom as well, so that it moves with the buttons (or perhaps better yet, lock the window height to the default, leaving just the width adjustable) Had a better idea what to do with the space between the controls and the buttons. :-)
NEW: ReplacePlus example: Display the list of processed files.
CHG: ReplacePlus example: Change text of action button depending on selected action (Replace or Touch).
Frequently_Asked_Questions
Scaling on High-DPI screens Legacy applications that are not DPI-aware are scaled by Windows by default (unless overridden in the Properties for the executable or in the general DPI and scaling settings in Windows). This may or may not be what you want. A problem on high-DPI screens, with or without the default scaling, is that the size of the original bitmap glyphs for the control bar may prove to be too small for comfort. For more info, see "Support for high-DPI" [feature-requests:#171] and related...
Hi, and welcome to the forum! Hi, firstly thanks to everyone who contributes here. Thanks! Much appreciated. I was able to get my old owl 5 program converted to owlnext 7 and its great. 64 bit and everything in VS2022 in a real treat. That's great to hear! Please post a review. The only issue i have remaining before testing is the TControlBar for all the shortcut buttons. The old one works fine but its way too small on a high res monitor. As AI suggested, you can create larger source bitmaps. For...
Hi, firstly thanks to everyone who contributes here. I was able to get my old owl 5 program converted to owlnext 7 and its great. 64 bit and everthing in VS2022 in a real treat. The only issue i have remaining before testing is the TControlBar for all the shortcut buttons. The old one works fine but its way too small on a high res monitor. Based on advice by AI i have creaded a strip bitmap 32 pixels high by 20 images. 20x32. To create the bitmap i downloaded a bunch of png icons from google materials...
@jogybl, it works great, thanks! Consider activating persistent window position by setting the the new flag wfPersistentExtent [feature-requests:#258] on the main window (and disable it for the client). Also, the title for the default button ("Replace") should become "Touch" when the touch action is selected, perhaps? And the action "Find" should actually be named "Replace", shouldn't it? PS. For some further polish, align buttons Replace, Close and Help to the right with closer spacing, similar...
@jogybl, it works great, thanks! Consider activating persistent window position by setting the the new flag wfPersistentExtent [feature-requests:#258] on the main window (and disable it for the client). PS. For some further polish, align buttons Replace, Close and Help to the right with closer spacing, similar to wizard conventions, and align the horizontal separator line to the bottom as well, so that it moves with the buttons (or perhaps better yet, lock the window height to the default, leaving...
OWLMaker
In discussion: https://sourceforge.net/p/owlnext/discussion/97175/thread/8cbc674381/?limit=100#7630 @sebas_ledesma wrote: This is a sample code to detect BOM and load a text file with the corresponding translation. I've done a quick code review. First, the important stuff: You need error checking. Your myFgets function may truncate the line read due to the use of fixed-size buffers. Tip: Allocate buffers (e.g. std::vector) of size 4 times maxLen instead. That should cover even extreme cases, in which...
In discussion: https://sourceforge.net/p/owlnext/discussion/97175/thread/8cbc674381/?limit=100#7630 @sebas_ledesma wrote: This is a sample code to detect BOM and load a text file with the corresponding translation. I've done a quick code review. First, the important stuff: You need error checking. Your myFgets function may truncate the line read due to the use of fixed-size buffers. Tip: Allocate buffers (e.g. std::vector) of size 4 times maxLen instead. That should cover even extreme cases, in which...
Here it's a sample code of writeBOM [...and...] myFputs. Quick code review: The byte order marks for UTF-32 are wrong. You need error checking. Your myFputs function may truncate lines due to the use of fixed-size buffers. Tip: Use dynamic allocation instead. MultiByteToWideChar and WideCharToMultiByte can be called with a nullptr to calculate the size of the buffer needed. For feedback on coding style etc, see my earlier code review for myFgets. Here is some (untested) modern C++ for writing the...
ReplacePlus: Resizable program window
Implemented in [r8766].
NEW: ReplacePlus: Resizable program window ([feature-requests:#217]).
Add support for image lists in TButton
Linker error _owlpch_dummy
Changes to TEdit and TRichEdit implemented in [r8763] and [r8764].
CHG: Updated TEdit and TRichEdit examples to use the new margin methods ([bugs:#559]).
CHG: Added TEdit::SetMargins method. See [bugs:#559].
CHG: Removed the deletion of the margin related methods in TRichEdit and implemented the RichEdit specific override of SetMarginUseFontInfo. See [bugs:#559].
Problems with the implementations of EM_SETMARGINS and EM_GETMARGINS
The simple fix for the potential buffer overflow has been merged to the branches 7 (in [r8760], 6.44 (in [r8761]) and 6.36 (in [r8762]).
OWLNext_Stable_Releases
Merged [r8759] from trunk:
Merged [r8759] from trunk:
Merged [r8759] from trunk:
BUG: Implemented the quick fix for the potential buffer overflow in TFileDocument::GetProperty ([bugs:#573]).
OwlExt::TCalcEdit and TCalendarEdit always display the popup on the primary monitor
CHG: TDialogRes example: Added a ShowDialog button that displays a dummy instance of the selected dialog template.
Many thanks Ognyan, that solved my problem. I looked all the time into the wrong direction. From: feature-requests@owlnext.p.re.sourceforge.net On Behalf Of Ognyan Chernokozhev Sent: Friday, 10 April 2026 22:42 To: [owlnext:feature-requests] 279@feature-requests.owlnext.p.re.sourceforge.net Subject: [owlnext:feature-requests] #279 Linker error _owlpch_dummy This error refers to two different libraries: owl-7.0-v1920-x86-dt.lib owl-7.0-v1920-x86-5dt.lib the second one is the OWL5 compat library. Looks...
C++23 Support in MSVC Build Tools 14.51
This error refers to two different libraries: owl-7.0-v1920-x86-dt.lib owl-7.0-v1920-x86-5dt.lib the second one is the OWL5 compat library. Looks like some of the code is compiled with OWL5_COMPAT and some is compiled without it.
Linker error _owlpch_dummy
CHG: More improvements to TDialogRes. See comment in [bugs:#593].
TDialogRes overhaul
Merged [r8754] from trunk to branches/owlet:
Merged [r7477] from trunk to branches/owlet:
After the overhaul to implement support for extended dialog templates [bugs:#593], here is a patch with some further clean-up you might consider: CHG: TDialogRes is now final. CHG: TDialogRes::Resource is now a TResource instance, not a pointer to an instance. CHG: TDialogRes destructor has been eliminated. CHG: TDialogRes::IsOK is deprecated, and now always returns true. CHG: TDialogRes::GetSize is now inline and returns int, not DWORD. CHG: TDialogRes implementation now uses TResource::Get rather...
After the overhaul to implement support for extended dialog templates [bugs:593], here is a patch with some further clean-up you might consider: CHG: TDialogRes is now final. CHG: TDialogRes::Resource is now a TResource instance, not a pointer to an instance. CHG: TDialogRes destructor has been eliminated. CHG: TDialogRes::IsOK is deprecated, and now always returns true. CHG: TDialogRes::GetSize is now inline and returns int, not DWORD. CHG: TDialogRes implementation now uses TResource::Get rather...
NEW: TResource::Get, const and non-const, for nicer API.
Note: The fix can be backported to the 7 and 6.44 branches, but it may bot be worth it if noone is actually using the TMailer code - and if they do, they should have already implemented their own checks for MAPI availability.
TMailer does not work if the application bitness differs from Outlook
TMailer should not throw exception when user cancels
BUG: TMailer does not work if the application bitness differs from Outlook ([bugs:#640]).
TMailer does not work if the application bitness differs from Outlook
TMailer should not throw exception when user cancels
CHG: Minor correction in TDialogRes::InitDialogData. See comment in [bugs:#593].
TShellItem::TBrowseFlags are ill-defined
For the records, @jogybl has now merged the fix into the trunk [r8748], branches/7 [r8749], branches/6.44 [r8750] and branches/6.36 [r8751] for release in OWLNext 7.0.21, 6.44.29 and 6.36.14. Thanks! PS. This is technically a breaking API change, but presumably, it is unlikely there are applications relying on the old incorrect values of these flags. The flags are not used anywhere within OWLNext, so ABI compatibility should be retained.
Another possible issue in [r8747] is this test: DialogData.FontItalic = ParseField_<BYTE>(s) == TRUE; This means that e.g. with the parsed BYTE equal to 0xFF (all bits set), the expression evaluates to false, since the BYTE is not equal to TRUE (0x01). This is usually fixed by always writing != FALSE instead. But this one is very easy to forget, as I can attest to myself!
@jogybl wrote: Thanks. I have applied and tested the change in [r8746]. Good to hear it passed testing! I made a minor refactoring of ConvertToString_, separating the control class lookup into a new function ConvertToControlClass_, just for better separation of concerns, but this is not that important here. Regarding [r8747], there is an issue in your change of the test for the font fields: - if (DialogData.Style & DS_SETFONT) + if ((DialogData.Style & DS_SETFONT) || (DialogData.Style & DS_SHELLFONT))...
OWLNext_Stable_Releases
TShellItem::TBrowseFlags are ill-defined
Merged [r8748] from trunk:
Merged [r8748] from trunk:
Merged [r8748] from trunk:
Merged [r8703] from branches/owlet:
Thanks. I have applied and tested the changes in [r8746].
CHG: TDialogRes::TDialogData: Added FontWeight, FontItalic and FontCharset properties.
CHG: TDialogRes::InitDialogData refactoring.
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
Note that the related issues I mentioned in the ticket description remain unresolved. I’m not using these components anymore, so I won’t be filing separate tickets, but the information is here if someone with interest in TShellItem/TPidl wants to follow up. Also see "Improve Shell abstractions" [feature-requests:#277].
TShellItem::GetTypeName accesses freed PIDL (regression in 6.32 [r867])
@jogybl wrote: I tried to use AI to generate the code for this, and some of the work was done by it Even if you use AI to generate code, having AI review the code in a fresh prompt can be useful. Maybe use a different AI for the review, and use the smartest AI you have access to (in thinking mode, so that it thinks before it speaks). Here's the code in "InitDialogData" I couldn't unsee: if ((pItems - p) % 2 == 0) { // Align to DWORD boundary ++pItems; } This baffled me and Copilot alike, and it took...
The fix for this issue has now been merged into branches/7 [r8736] for release in OWLNext 7.0.21. PS. @jogybl, consider releasing updates for 6.44 and 6.36 with this fix as well. Or change the milestone, if not. Edit: The fix has now been merged into branches/6.44 [r8742] and branches/6.36 [r8744] for release in OWLNext 6.44.29 and 6.36.14, respectively. Thanks!
OWLNext_Stable_Releases
CHG: branches/6.36: Updated version number to 6.36.14 and set OWL_PRERELEASE to 1.
Merged [r8736] from branches/7:
CHG: branches/6.44: Updated version number to 6.44.29 and set OWL_PRERELEASE to 1.
Merged [r8736] from branches/7:
I tried to use AI to generate the code for this, and some of the work was done by it, but I had to make a number of corrections, including I think omitting the star in statements like (ushort)*(pControlClass + 1). The currently tested dialogs may be deceptively regular. Yeah, I am not sure the code would be handling correctly the case in which controls have extra bytes. Will need more research when I get back to this.
Contributing
Hi Ognyan, Good work on fixing this! This kind of low-level binary parsing, with potential alignment issues and pointer arithmetic corner cases, is tricky to get right, so good of you to add a test case in Classes — which seems to work nicely! Have you had your code reviewed by AI? I'm trying not to get involved on the trunk, so I just asked Windows Copilot (Smart) to have a look at your InitDialogData, and it complained about a few issues with alignment, type casts and pointer arithmetic in places....
The GetText function is now replaced with a GetDialogData function that returns a struct with the parsed members of the dialog template.
TDialogRes::GetText crashes for extended dialog template
TDialogRes overhaul
With the changes in [r8737] the overhaul of the TDialogRes class is done for now. The class correctly handles both classic and extended templates and also retrieves the list of controls in the templates, as demonstrated in the new TDialogResTest example in the Classes project. In the future, if requested, functions for manipulating the templates can be added.
CHG: Classes: Added the dialogres.bmp file.
CHG: Classes: Added icon for the TDialogRes example.
CHG: Classes: TDialogRes test dialog is now resizable.
CHG: Classes: TDialogRes example: Display the list of controls extracted from the dialog template.
Frequently_Asked_Questions
Main_Page
CHG: Removed deprecated TDialogRes functions.
