C++ Language Updates in MSVC Build Tools v14.50
Note: the free Community Edition is still 12.1 Athens
Announcing the Availability of RAD Studio 13 Florence
Another possibility may be to use vector icons in toolbar. Something to try may be to include an icon font file FontAwesome in the application, and use its glyphs, by making a text toolbar button with the font set to the icon font.
New version 1.1.5 of FolderSize tool is released.
CHG: FolderSize example: Updated Options dialog screenshot.
CHG: FolderSize example: Fixed typo in comment.
CHG: FolderSize example: Hide the "Show in Explorer context menu" button when publishing Windows Store application.
CHG: FolderSize example: Updated version to 1.1.5 in preparation for release.
CHG: FolderSize example: Optimized the file icons image list to avoid adding duplicate icons to it.
CHG: FolderSize example: Added setting whether to show file icons.
NEW: FolderSize Example: Retrieve and display the actual file icons in the files list.
Hi, The examples look great. But there is a small problem with the configurations, that out-of-the box only the Release|x64 can be build. The options in the others are not set correctly - for example missing the paths to OWLNext, inconsistent DLL and charset options and some other problems. I fixed the configurations first example - Alpha Blending - and added a full range of configurations, including Static builds and Unicode builds and made some minor changes in the source to enable it to build...
You are right, there isn't a use case for this control, as the standard date picker is clearly superior. We can just put a comment in the header file that it should not be used and point to TDateTimePicker.
Change TCalendarEdit to use the standard Month Calendar control
Implemented in [r7860].
CHG: Change TCalendarEdit to use the standard Month Calendar control ([feature-requests:#263]).
The second proposed fix implemented in [r7859].
Change TCalendarEdit to use the standard Month Calendar control
TCalendarEdit text gets cleared when control loses focus
BUG: TCalendarEdit text gets cleared when control loses focus ([bugs:#610]).
The problem is that TDate::AsString() by default uses the "mmm dd,yy" format for printing the date, the parsing is done using the TDate(LPCTSTR) constructor, which internally calls TDate::ParseFrom(LPCTSTR str, LPCTSTR format), and its implementation does not support the "mmm dd,yy" format. Two possible quick fixes for the TCalendarEdit class: Use TDate::SetPrintOption(TDate::WinIntSection) to set the format for TDate::AsString() when setting the text in the edit control. The problem is that first...
TCalendarEdit text gets cleared when control loses focus
@vattila Great work on the menu changes! There is a minor thing that bugs me a bit - the need for the TViewHostingMDIChild class in the RichEditor example solely for returning the view menu descriptor. It is not obvious that the user needs to create such class in order to have menu bitmaps correctly in a docview application. Isn't it viable instead to implement this functionality in either TMDIChild or even TFrameWindow - if there is no menu descriptor assigned to it, then check the client window,...
This is the case in which event handlers would automatically make use of a resource only if it does exist, right? Yes, it seems reasonable to try first with FindResource and if not present, then not try to actually load it.
CHG: Refactored code in TCalcEdit, TCalendarEdit and TPickEditList to use the new override TSystem::GetMonitorWorkArea. See [bugs:#606].
@vattila Thanks for the additional fixes for the TCalc class. I think most of the fixes can be merged to the released branches.
However, the entanglement of child ID and window menu handle goes deeper, it seems. Since child windows cannot have menus, I suspect the window menu handle and child ID are stored in a union internally. Ah, yes. That makes sense. Probably another relic from the 16-bit Windows and the limited memory of that era.
What would be cool: Let the user type an expression and have it evaluated immediately (e.g by pressing F9, mimicking similar functionality in spreadsheets). That could be a functionality for new different control. Never tried it, but looking at the code, the format should be something like this: That would be my guess too. I might give it a try. Still, it seems a strange design decision to not have that ability to pass the list directly as some data structure, which will give the user of the control...
OWLExt TCalcEdit and TCalEdit always display the popup on the primary monitor
Quick fix for all three controls in [r7749]. Note - since all three controls use the same code to get the current monitor screen rectangle, that code should be moved in a shared place, for example in owlext.cpp, which already contains a number of similar utility functions.
BUG: OWLExt TCalcEdit and TCalEdit always display the popup on the primary monitor ([bugs:#606]).
OWLExt TCalcEdit and TCalEdit always display the popup on the primary monitor
In OWLExt library there are several controls, all derived from TPopupEdit: TCalcEdit - a numeric edit control that can pop up a calculator (which seems to be based on the old OWL5 calculator example) TCalEdit - a date edit control that can popup a calendar. The calendar that is displayed is custom drawn. It will be better if it uses instead the TMonthCalendar common control. TPickEditList - it seems to read a text file with data to display, but I cannot find an explanation or example of what the...
NEW: Classes samples: Added examples for the OWLExt classes TCalcEdit and TCalEdit.
BUG: OWLExt TCalc calls UpdateDisplay after being closed, which causes a precondition in debug builds.
Very interesting find. Looking at the source, I can see that this is the behavior from the original OWL 5. I wonder if it was somewhat related to the list of child windows that can be displayed in the Windows menu.
Initial implementation in [r7676]. TODO: Add a suitable icon to the new context menu item Security concern - should the user be warned when trying to launch an executable file (.exe, .bat, etc.)?
CHG: FolderSize example: Added Open File menu and double-click action. See [feature-requests:#259].
FolderSize: Add OpenFile function
Cool! Also feel free to push the changes directly to the repo. I am testing the latest and they look fine.
I don't have much preference for using ini files versus registry. One argument about continuing to use ini files is backwards compatibility, but that may not function well, as the names of some settings are changed. But I think it is ok to reset settings after upgrade to a new version. One aspect where registry is better is that it makes it less likely the user will mess up with the settings, and especially the child windows count, sizes and positions is not something the user should try to edit...
Hi, As a first step, I just pushed a quick fix, because the project was not compiling. I will refactor it to use the new app settings functionality - many thanks for implementing that. A question - how would it be best to combine the new way of storing window sizes and positions with the way that FolderSize tries to preserve child windows, based on the root folder that is selected for each one?
CHG: Updated FolderSize example to use new window extent persistence.
No problem :-) And thanks for making the release. I will do more testing now.
Updated the files-readme.md with the correct links.
6.36 also downloads 6.36.10
I tried to download 6.44 with OWLMaker, but the version that got downloaded is 6.44.25
New in RAD Studio 12.3: 64-bit IDE Initial Release! https://blogs.embarcadero.com/new-in-rad-studio-12-3-64-bit-ide-initial-release/
Great work! Now everything build with the compilers I am testing with.
Interesting that it fails with VC++ 2010 and 2015, but not with 2022.
Trying to build latest 6.36 and getting this linker error: 34> owl-6.36.11-v10-x86-ti.lib(global.obj)(0,0): error LNK2019: unresolved external symbol "public: bool __thiscall owl::TSTypedArray<double,double,class owl::TStandardAllocator>::Destroy(int)" (?Destroy@?$TSTypedArray@NNVTStandardAllocator@owl@@@owl@@QAE_NH@Z) referenced in function "void __cdecl owl::`anonymous namespace'::Test_TSortedPtrArray(void)" (?Test_TSortedPtrArray@?A0x9c184c32@owl@@YAXXZ)
Announcing the Availability of RAD Studio 12.3 Athens
CHG: Replaced tabs with spaces.
CHG: Added more debug code for testing Classlib template code.
CHG: Replaced tabs with spaces.
CHG: Temporary debug code for testing the Classlib template fixes.
BUG: TDequeAsVector and TIDequeAsVector (classlib/deques.h) fails to compile with Clang C++Builder. See [bugs:#491].
CHG: Replaced tabs with spaces.
TDequeAsVector and TIDequeAsVector (classlib/deques.h) fails to compile with Clang C++Builder
CHG: 6.44: Set OWL_PRERELEASE to 1.
CHG: 6.36: Set OWL_PRERELEASE to 1.
Merged [r7502] from branches/6.44:
BUG: Improved fix for TSArrayAsVector and TISArrayAsVector. See [bugs:#488].
NEW: WebView2 sample: Added example of using a WebView2 browser in a dialog.
Reopening the issue. See discussion https://sourceforge.net/p/owlnext/discussion/97177/thread/4b657931fa/
TSArrayAsVector and TISArrayAsVector (arrays.h) fails to compile when using Clang based C++Builder
CHG: WebView2 example: Fixed warnings about uninitialized members.
For example, tried to change the INTERNET_OPEN_TYPE_DIRECT with INTERNET_OPEN_TYPE_PRECONFIG in the call to InternetOpen. That did not help, but it may be a good idea to change it. I think I also tried to set the SECURITY_FLAG_IGNORE_REVOCATION using InternetSetOption, but could not get that to work at all. Today, I did some more tests, and the interesting thing is that when I try the Check For Updates, or Download Source Code, on first attempt it fails with this error, but on second attempt it is...
Great job! The new build works on that machine. There is another issue with OWLMaker, but I guess it is due to some internet configuration - it cannot connect and check for update or download sources - the error is ERROR_INTERNET_SEC_CERT_REV_FAILED. While connecting with browser and downloading works. I tried few things, but so far nothing helped.
Hi, Thanks for the fix. It resolves the issue on start of the build. Unfortunately, there is one more place that depends on the ICU library, in Util.cpp auto FormatDuration(chrono::system_clock::duration d) -> tstring { using namespace chrono; return (tostringstream{} << hh_mm_ss{round<seconds>(d)}).str(); } auto FormatTime(chrono::system_clock::time_point tp) -> tstring { using namespace chrono; const auto ltp = current_zone()->to_local(tp); return FormatDuration(ltp - floor<days>(ltp)); }
OWLMaker crashing on a Windows Server machine
CHG: OwlMaker: Added two more internet error codes to be reported in ThrowLastError.
CHG: WebView2 example: Fixed an issue where the About message is not showing on first load of web page.
CHG: WebView2 sample: Added an About message dialog displayed in the browser.
CHG: WebView2 example: Updated the WebView2 package.
It should work. This code: TLvItem::TListState state = static_cast<TLvItem::TListState>(TLvItem::TListState::Focus | TLvItem::TListState::Selected); results in state having the integer value of 3 (Focus value is 1 and Selected value is 2), even if it is not defined as a member of the enum. Using an enum instead of plain uint makes it clearer what are the accepted values for the parameter.
Have you tried combining the enum values and then casting to TLvItem::TListState? SetItemState(row, static_cast<TLvItem::TListState>(TLvItem::Selected | TLvItem::Focus), mask);
CHG: FolderSize example: Updated TVersionHistoryDialog for latest changes in TResizableDialog.
CHG: OWLMaker example: Renamed class TClassesMDIClient to TFolderSizeMDIClient.
CHG: OWLMaker example: Removed unused experimental code in TFolderSizeApp constructor.
Great idea! This class seems to be an incomplete implementation leftover from BC5.02/OWL5 days and not touched since.
NEW: Added footer controls to the Clear Output Folders dialog that show the file and size totals.
CHG: Updated TClearOutputFoldersDlg code to conform with the change in TResizableDialog.
CHG: Removed the virtual base of TResizableDialog. See https://sourceforge.net/p/owlnext/discussion/97177/thread/a23e20ac7b/.
And here are some in-depth posts regarding dialogs from Raymond Chen's blog: The evolution of dialog templates – Introduction https://devblogs.microsoft.com/oldnewthing/20040617-00/?p=38833 The evolution of dialog templates – 16-bit Classic Templates https://devblogs.microsoft.com/oldnewthing/20040618-00/?p=38803 The evolution of dialog templates – 32-bit Classic Templates https://devblogs.microsoft.com/oldnewthing/20040621-00/?p=38793 The evolution of dialog templates – 16-bit Extended Templates...
Here are the main parts of the code that I have used in the past to make dialog fonts to scale: //https://stackoverflow.com/questions/14370238/can-i-dynamically-change-the-font-size-of-a-dialog-window-created-with-c-in-vi #pragma pack(push, 1) // exact fit - no padding struct DLGTEMPLATEEX_PART1 { WORD dlgVer; WORD signature; DWORD helpID; DWORD exStyle; DWORD style; WORD cDlgItems; short x; short y; short cx; short cy; }; #pragma pack(pop) static BYTE* AdvanceThrough_sz_Or_Ord(BYTE* pData) { //'pData'...