Activity for OWLNext: C++ Application Framework
-
Vidar Hasfjord posted a comment on discussion Open Discussion
@luigibianchi wrote: Maybe we can arrange a web meeting in which we share ideas, comments, etc [...] I believe it would be beneficial to discuss a potential migration to a different framework and exchange tips or insights. For future reference, and to allow everyone to participate, I propose we use this discussion thread to share and discuss anything related to using AI for porting OWL/OWLNext applications to another framework (and possibly programming language). Some wiki pages demonstrating how...
-
@sebas_ledesma wrote: Even switching from 'classic C++' to 'modern c++' requires work. AI is rapidly becoming superhuman for such tasks. Take for example your still open feature tickets: TCoolEdit: Syntax highlighting for JSON files [feature-requests:#268]. TCoolEdit: Syntax highlighting for XML files [feature-requests:#269]. With the latest modernisation of TCoolEdit, the code for these parsers are now outdated and need rewriting, as I noted in ticket comments (#9034, #5bd4). Presumably, the tickets...
-
Luigi Bianchi posted a comment on discussion Open Discussion
I believe it would be beneficial to discuss a potential migration to a different framework and exchange tips or insights. Transitioning from OWLNext would require significant effort and might even be impractical. Based on my research, while Qt is more powerful, it may require a commercial license insome cases; wxWidgets, on the other hand, is free but less feature-rich. However, I have already identified equivalent classes in wxWidgets for my needs, so if I do migrate, that will be my choice.
-
Sebastian Ledesma posted a comment on discussion Open Discussion
For me, switching LARGE projects to another language, even with IA aid, it's technically and economically impractical. Even switching from 'classic C++' to 'modern c++' requires work. Moreover, after you move to another framework/language using IA you have to audit that conversion. I've have used VCL and FMX in small applications, they are technically very good, but you'll depend on Borland/Embarcadero compilers. QT and wxWidgets are more open. wxWidgets was also recommended by the same Borland as...
-
@jogybl wrote: [Microsoft going] from C++ to Rust using AI Rust has quickly become very popular as a more secure alternative to C++, notably mentioned by governments as one of the safe languages that should be used instead of C and C++. Hopefully, C++ can get Bjarne Stroustrup's security profiles soon (or better yet, support for Herb Sutter's Cpp2). Do you mean another similar C++ framework like wxWidgets, or different platform like WinUI3? Any modern language and active framework may apply, I guess,...
-
@jogybl wrote: [Microsoft going] from C++ to Rust using AI Rust has quickly become very popular as a more secure alternative to C++, notably mentioned by governments as one of the safe languages that should be used instead of C and C++. Hopefully, C++ can get Bjarne Stroustrup's security profiles soon (or better yet, support for Herb Sutter's Cpp2). Do you mean another similar C++ framework like wxWidgets, or different platform like WinUI3? Any modern language and active framework may be apply, I...
-
Ognyan Chernokozhev posted a comment on discussion Open Discussion
There was recent news about Microsoft converting their codebase from C++ to Rust using AI - but they needed to clarify that it is still only a research project on the viability of it. Rather than continue to promote OWLNext as a permanent solution for old OWL applications, is it time to recommend using AI to port to a better modern framework instead? Do you mean another similar C++ framework like WxWidgets, or different platform like WinUI3? Because the latter seems to be not so much as porting code,...
-
Dear Vidar, you raised a very interesting point. Maybe we can arrange a web meeting in which we share ideas, comments, etc... However, I have one big question: which "modern" framework are you considering? wxWidgets? Qt?
-
Gianni Rossi posted a comment on discussion Open Discussion
Hi Vidar, Your observation is very interesting. As you know, I am still maintaining a very large BC++5.02 / OWL application. Do you think that by using AI, I could skip the transition to OWLNext and rewrite it from scratch for a modern framework? If so, could you give me some suggestions for undertaking this task? Thank you.
-
Over the last couple of years, AI-assisted software development has become practical. Rather than continue to promote OWLNext as a permanent solution for old OWL applications, is it time to recommend using AI to port to a better modern framework instead? At least, perhaps we should mention this new option in our wiki (porting guide, FAQ)? Anyone out there with experience using AI on OWL projects, esp. for rewriting or refactoring?
-
Over the last couple of years, AI-assited software development has become practical. Rather than continue to promote OWLNext as a permanent solution for old OWL applications, is it time to recommend using AI to port to a better modern framework instead? At least, perhaps we should mention this new option in our wiki (porting guide, FAQ)? Anyone out there with experience using AI on OWL projects, esp. for rewriting or refactoring?
-
Over the last couple of years, AI has emerged as an impressive tool for coding. Rather than continue to promote OWLNext as a permanent solution for old OWL applications, is it time to recommend using AI to port to a better modern framework instead? At least, perhaps we should mention this new option in our wiki (porting guide, FAQ)? Anyone out there with experience using AI on OWL projects, esp. for rewriting or refactoring?
-
Windows API header "tmschema.h" is obsolete
-
Double Condemn causes hang
-
Exception in constructor of TView subclass causes crash
-
@jprenz wrote: Test cases now run smoothly and without incident. Super! Thanks for testing and feedback, and thanks for reporting this issue. Upcoming updates will include the fix.
-
My proposed fix has now been committed on the trunk [r8588] and merged into branches 6.36, 6.44, 7 and Owlet [r8589]. (Edit: A regression has been fixed on the trunk [r8590] and branches [r8591].) Please review.
-
Jörg Prenzing posted a comment on ticket #634
I did some testdriving with r8588/r8859 and experienced intermitting crashes in TWindow::RemoveChild() while condemning TWindow-Instances. r8590/r8591 seem to fix this, Test cases now run smoothly and without incident.
-
OWLNext_Stable_Releases
-
My proposed fix has now been committed on the trunk [r8588] and merged into branches 6.36, 6.44, 7 and Owlet [r8589]. (Edit: A regression has been fixed on the trunk [r8590] and merged into the branches [r8591].) Please review.
-
Merged [r8590] from trunk to branches/(6.36|6.44|7|owlet):
-
RGR: TApplication::Condemn: SetParent crashes [r8588].
-
Double Condemn causes hang
-
My proposed fix has now been committed on the trunk [r8588] and merged into branches 6.36, 6.44, 7 and Owlet [r8589]. Please review.
-
OWLNext_Stable_Releases
-
Merged [r8588] from trunk to branches/(6.36|6.44|7|owlet):
-
BUG: Double Condemn causes hang [bugs:#634].
-
Double Condemn causes hang
-
This ticket is a duplicate of ticket [bugs:#368] "The same TWindow object can be condemned more than once". Unfortunately, the fix [r3773] was incomplete, in that the last entry in the CondemnedWindows list was not checked, as pointed out by this ticket. On further code review, there is another issue: If a double condemnation is detected, the next-pointer of the window has already been cleared, thereby truncating the list. I propose the following fix for both issues: void TApplication::Condemn(TWindow*...
-
It turns out that the fix [r3773] does not check the last entry in the CondemnedWindows list. Unfortunately, this issue slipped through our code review. See earlier ticket comment. @jprenz ran into this issue in version 7, and has filed a new ticket [bugs:#634].
-
Double Condemn causes hang
-
Double Condemn
-
@nevering wrote: What would you recommend as best path for compiler to use to get this rolling? Both the Microsoft and Embarcadero toolsets should work well. See Supported Compilers for more advice. I’m also seeing an error in my regular application regarding a "busy clipboard error” The clipboard may occasionally be busy, so you have to be prepared for this error. For robust code, check for the error, insert a delay and retry. However, sometimes inserting a fixed delay will do. I recently made use...
-
@nevering wrote: What would you recommend as best path for compiler to use to get this rolling? Both the Microsoft and Embarcadero toolsets should work well. See Supported Compilers for more advice. I’m also seeing an error in my regular application regarding a "busy clipboard error” The clipboard may occasionally be busy, so you have to be prepared for this error. For robust code, check for the error, insert a delay and retry. However, sometimes inserting a fixed delay will do. I recently made use...
-
Hi Sebastian, I hope you are still around! Over the last couple of days, I have been looking closer at the support for UTF provided in the C++ standard. Initially, it looked promising — there are a quite a few facilities in the standard library to handle UTF conversions — but then I realised that most of them are deprecated. For example, the class templates codecvt_utf8, codecvt_utf16 and codecvt_utf8_utf16 are all deprecated, as are wbuffer_convert and wstring_convert. This has made it a nightmare...
-
Hi Sebastian, I hope you are still around! Over the last couple of days, I have been looking closer at the support for UTF provided in the C++ standard. Initially, it looked promising — there are a quite a few facilities in the standard library to handle UTF conversions — but then I realised that most of them are deprecated. For example, the class templates codecvt_utf8, codecvt_utf16 and codecvt_utf8_utf16 are all deprecated, as are wbuffer_convert and wstring_convert. This has made it a nightmare...
-
@jogybl wrote: The next set of errors [related to std::codecvt and Unicode] See "Unicode support in CoolPrj" [feature-requests:#54], especially my last comment. The Embarcadero toolset may not support the std::codecvt features I've used to implement support for reading and writing Unicode. The best solution may be to rewrite the code to no longer rely on these (deprecated) facilities. I surmise that rewriting these functions from scratch (with the help of AI) may not take much effort. Feel free to...
-
Unicode support in CoolPrj
-
The next set of errors: 13> "C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj" (Clean;Build target) (1) -> 13> (_CLANGCoreCompile target) -> 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\fstream(425,29): error E4974: implicit instantiation of undefined template 'std::codecvt<char8_t, char, _Mbstatet>' [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj] 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\__locale(167,24):...
-
The last set of errors: 13> "C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj" (Clean;Build target) (1) -> 13> (_CLANGCoreCompile target) -> 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\fstream(425,29): error E4974: implicit instantiation of undefined template 'std::codecvt<char8_t, char, _Mbstatet>' [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj] 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\__locale(167,24):...
-
CHG: Removed obsolete C++ Builder specific conditional code.
-
CHG: Renamed syntaxhighlightingconfigurationdlg.cpp to settings.cpp in CoolPrj C++ Builder project. See [feature-requests:#267].
-
CHG: Another fix for compilation issue with C++ Builder 13. See [feature-requests:#267].
-
A possible solution: Replace the line FontVariants = {}; with FontVariants.clear();
-
Thanks, that works. The next error is 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\unordered_map(895,13): error E4632: no viable overloaded '=' [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj] 13> 895 | __ref() = std::forward<_ValueTp>(__v); 13> | ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\__hash_table(1263,44): Hint warning H5849: in instantiation of function...
-
CHG: Fix for compilation issue with C++ Builder 13. See [feature-requests:#267].
-
@jogybl wrote: Interesting that the same code compiles with C++ Builder 12 and Visual C++ Apparently, those compilers delay the relevant error‑checking until instantiation time, which makes them more permissive, if not strictly standard‑compliant.
-
@jogybl wrote: And C++ Builder 12 fails to compile CoolPrj [...] This is deliberate. C++Builder 12 is not C++20 compliant and for this reason no longer supported on the trunk. In my latest work on CoolPrj, I started using C++20 features not supported by this compiler. The errors are hence expected.
-
@jogybl wrote: With C++ Builder 13, CoolPrj fails to build with error [...] E1927: a template argument list is expected after a name prefixed by the template keyword The standard apparently requires a template argument list after Encode, since it is prefixed by the template keyword (which is required for disambiguation, because Encode is a dependent name). We want argument list type deduction here, since specifying it is a little bit awkward (Encode<decltype(sendMessage)>). Fortunately, according...
-
And C++ Builder 12 fails to compile CoolPrj with the error 13> ..\..\include\coolprj/textbuffer.h(41,10): error E2771: 'operator<=' cannot be the name of a variable or data member [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj] I guess it cannot handle the 'spaceship' operator?
-
With C++ Builder 13, CoolPrj fails to build with error 13> In file included from ..\..\include\coolprj/cooledit.h:15: 13> ..\..\include\coolprj/source.h(380,62): error E1927: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw] [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\coolprj.cbproj] 13> 380 | return D<M>::template TNotificationDispatch<N>::template Encode(sendMessage, nullptr, std::forward<A>(a)...); 13> | ...
-
Moving the operators to from the .cpp to the .h solves this issue. ([r8583])
-
CHG: Moved TCodePage comparison operators from the source file to the header to resolve compilation issue with C++ Builder 13. See [feature-requests:#267].
-
Actually, the operators are there, but defined in the .cpp and not in the header.
-
Interesting that the same code compiles with C++ Builder 12 and Visual C++ I can try to add the operator to see if that helps.
-
@pralkopodobny wrote: I believe I'm not familiar enough with either OCF or OLE to fix this issue Thanks for the feedback. Indeed, the issue seems to be a tricky and unfortunate circular cleanup matter, as I described in my earlier posts here, and may require some redesign to be fixed properly. I've left the ticket open, while relieving you of ownership and resetting the milestone to "unspecified". If you, or anyone else, would like to take a fresh look at some point, feel free to update the tick...
-
@pralkopodobny wrote: I believe I'm not familiar enough with either OCF or OLE to fix this issue Thanks for the feedback. Indeed, the issue seems to be a tricky and unfortunate circular cleanup matter, as I described in my earlier posts here, and may require some major cleanup to be fixed properly. I've left the ticket open, while relieving you of ownership and resetting the milestone to "unspecified". If you, or anyone else, would like to take a fresh look at some point, feel free to update the...
-
@martinabc wrote: Is there a change I need to make to the template so that it will appear in Visual Studio 2022? I dont' think so. I have installed the template successfully in Visual Studio 2022, following the instructions on our wiki. I did some further testing and ran into some problems making it appear again after I removed it. There may be an issue with updating the template cache or something. Copilot suggested running: devenv /installvstemplates This helped somewhat, but I still couldn't get...
-
@pralkopodobny wrote: I believe I'm not familiar enough with either OCF or OLE to fix this issue Thanks for the feedback. Indeed, the issue seems to be a tricky and unfortunate circular cleanup issue, as I described in my earlier posts here, and may require some major cleanup to be fixed properly. I've left the ticket open, while relieving you of ownership and resetting the milestone to "unspecified". If you, or anyone else, would like to take a fresh look at some point, feel free to update the ...
-
Crash in TOcPart::Close function
-
@pralkopodobny wrote: I believe I'm not familiar enough with either OCF or OLE to fix this issue Thanks for the feedback. Indeed, the issue seems to be a tricky and unfortunate circular cleanup issue, as I described in my earlier posts here, and may require some major cleanup to be fixed properly. I've left the ticket open, while releaving you of ownership and resetting the milestone to "unspecified". If you, or anyone else, would like to take a fresh look at some point, feel free to update the ...
-
Installing_the_OWLNext_Application_template_for_Visual_Studio
-
Installing_the_OWLNext_Application_template_for_Visual_Studio
-
OWLNext: C++ Application Framework updated /project-templates/project-templates-readme.md
-
Installing_the_OWLNext_Application_template_for_Visual_Studio
-
@martinabc wrote: Is there a change I need to make to the template so that it will appear in Visual Studio 2022? I dont' think so. I have installed the template successfully in Visual Studio 2022, following the instructions on our wiki. I did some further testing and ran into some problems making it appear again after I removed it. There may be an issue with updating the template cache or something. Copilot suggested running: devenv /installvstemplates This helped somewhat, but I still couldn't get...
-
Installing_the_OWLNext_Application_template_for_Visual_Studio
-
@jogybl wrote: Any ideas how to fix this [TCodePage related compilation bug]? TCodePage lacks a less-than operator, so presumably cannot be used with std::lower_bound without an explicit predicate (or a less-than operator needs to be defined for the type).
-
@jogybl wrote: Any ideas how to fix this [TCodePage related compilation bug]? TCodePage lacks a less-than operator, so presumably cannot be used with std::lower_bound without an explicit predicate (or a less-than operator needs to be defined for the type).
-
@martinabc wrote: Is there a change I need to make to the template so that it will appear in Visual Studio 2022? I dont' think so. I have installed the template successfully in Visual Studio 2022, following the instructions on our wiki. I did some further testing and ran into some problems making it appear again after I removed it. There may be an issue with updating the template cache or something. Copilot suggested running: devenv /installvstemplates This helped somewhat, but I still couldn't get...
-
@martinabc wrote: Is there a change I need to make to the template so that it will appear in Visual Studio 2022? I dont' think so. I have installed the template successfully on Visual Studio 2022, following the instructions on our wiki. I did some further testing and ran into some problems making it appear again after I removed it. There may be an issue with updating the template cache or something. Copilot suggested running: devenv /installvstemplates This helped somewhat, but I still couldn't get...
-
@sebas_ledesma, @vattila When trying to build the trunk with C++ Builder 13, I get errors: 1> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\__algorithm\comp.h(41,18): error E5133: invalid operands to binary expression ('const owl::TCodePages::TCodePage' and 'const owl::TCodePages::TCodePage') [C:\Work\OWLNext\Subversion\trunk\build\embarcadero\owl.cbproj] 1> 41 | return __lhs < __rhs; 1> | ~~~~~ ^ ~~~~~ 1> C:\Program Files (x86)\Embarcadero\Studio\37.0\include\x86_64-w64-mingw32\c++\v1\__type_traits\invoke.h(179,25):...
-
Hi Vidar, Many thanks for replying so quickly. I spent a long time with AI yesterday but still couldn't solve it, hence contacting you. I downloaded the OWLNext project template this morning as you suggested, but I have encountered problems there: I cannot get 'OWLNext application' to show up in Visual Studio 2022 when the template .zip file is placed in the folder Documents\Visual Studio 2022\Templates\ProjectTemplates\Visual C++ Project It does show up in Visual Studio 2019 when placed in Documents\Visual...
-
Erwin Lotter committed [r8582] on Code
branches/elotter-cooledit:
-
RGR: CmSwapLines included the last line of a selection even if the selection ended at column zero.
-
branches/elotter-cooledit:
-
It has the characteristics of a compiler bug. Have you tried making a test case you can explore with different compilers ... I know very little about how event dispatching works in OWLNext. Therefore, it would be difficult for me to create a usable test case.
-
Support for the Clang-based Embarcadero compilers
-
Update on Win64+UNICODE: Currently OWLMaker dont allow to build the UNICODE versions of OWLNext, OCFnext and other in Win64+UNICODE for C++Builder compilers (c++Builder clang) Using C:\OWL644\source\owlcore\CBXE3\owl.cbproj I've builded both Debug and Release version of OWLNext Win64+UNICODE. I've used C++Builder 10.x (10.1 actually). I've renamed them using the owlnext file name convention: https://sourceforge.net/p/owlnext/wiki/OWLNext_naming_convention/ Then I've opened small and medium projects...
-
Marceli Sokólski modified a comment on ticket #572
Hi @vattila, Sorry for not contacting you erlier. I was coming back to this issue from time to time and I really hoped to solve it. I tried to understand what is going wrong (and why), but after looking into it, I feel like there might not be a problem with OCF itself, but rather with the way I'm using it. Either way, I believe I'm not familiar enough with either OCF or OLE to fix this issue, especially without using workarounds (like the one described in my initial post or "quick" fix).
-
Hi @vattila, Sorry for not contacting you erlier. I was comming back to this issue from time to time and I really hoped to solve it. I tried to understand what is going wrong (and why), but after looking into it, I feel like there might not be a problem with OCF itself, but rather with the way I'm using it. Either way, I believe I'm not familiar enough with either OCF or OLE to fix this issue, especially without using workarounds (like the one described in my initial post or "quick" fix).
-
Martin Cohen modified a comment on discussion Open Discussion
Many thanks for looking at it Ognyan. I changed all occurrences of x86 to x64, and also all occurrences of Win32 to Win64 in the .vcxproj file and I got the same as you...the LNK1112 no longer occurs but I now get 288 'unresolved external symbol' linker errors. So I used AI to try to find out what was causing this and it advised me that I was missing the library files listed below. user32.lib;gdi32.lib;gdiplus.lib;comctl32.lib;ole32.lib;uuid.lib;shell32.lib;comdlg32.lib;advapi32.lib;oleaut32.lib...
-
Hi Vidar, Many thanks for replying so quickly. I spent a long time with AI yesterday but still couldn't solve it, hence contacting you. I downloaded the OWLNext project template this morning as you suggested, but I have encountered problems there: I cannot get 'OWLNext application' to show up in Visual Studio 2022 when the template .zip file is placed in the folder Documents\Visual Studio 2022\Templates\ProjectTemplates\Visual C++ Project It does show up in Visual Studio 2019 when placed in Documents\Visual...
-
Many thanks for looking at it Ognyan. I have changed all occurrences of x86 to x64, and also all occurrences of Win32 to Win64 in the .vcxproj file and I get the same as you...the LNK1112 no longer occurs but I now get 288 'unresolved external symbol' linker errors. I used AI to try to find out what was causing this and on its advice I added the following to the additional dependencies for the linker: user32.lib;gdi32.lib;gdiplus.lib;comctl32.lib;ole32.lib;uuid.lib;shell32.lib;comdlg32.lib;advapi32.lib;oleaut32.lib...
-
Many thanks for looking at it Ognyan. I have changed all occurrences of x86 to x64, and also all occurrences of Win32 to Win64 in the .vcxproj file and I get the same as you...the LNK1112 no longer occurs but I now get 288 'unresolved external symbol' linker errors. The first 20 lines or so of the Output window are shown below. Any thoughts on what is wrong would be much appreciated. ~~~ Build started at 6:22 AM... 1>------ Build started: Project: Template_OWLNEXT_App, Configuration: Debug x64 ------...
-
Many thanks for looking at it Ognyan. I have changed all references to x86 to x64, and also from Win32 to Win64, in the .vcxproj file and I get the same as you...the LNK1112 no longer occurs but I now get 288 'unresolved external symbol' linker errors. The first 20 lines or so of the Output window are shown below. Any thoughts on what is wrong would be much appreciated. ~~~ Build started at 6:22 AM... 1>------ Build started: Project: Template_OWLNEXT_App, Configuration: Debug x64 ------ 1>INPUTDLG.CPP...
-
Many thanks for looking at it Ognyan. I have changes all references to x86 to x64, and also from Win32 to Win64, in the .vcxproj file and I get the same as you...the LNK1112 no longer occurs but I now get 288 'unresolved external symbol' linker errors. The first 20 lines or so of the Output window are shown below. Any thoughts on what is wrong would be much appreciated. ~~~ Build started at 6:22 AM... 1>------ Build started: Project: Template_OWLNEXT_App, Configuration: Debug x64 ------ 1>INPUTDLG.CPP...
-
@pralkopodobny, is there any plan to resolve this issue? And if so, is there any prospect of getting it done soon to coincide with the release of the current pending issues? If not, I will retarget this ticket.
-
@pralkopodobny, is there any plans to resolve this issue? And if so, is there any prospect of getting it done soon to coincide with the release of the current pending issues? If not, I will retarget this ticket.
-
Registered developers now have permission to change tickets (bugs and feature requests), e.g. take ownership, edit labels, set milestone, modify the description, etc. So, if you want to take on one of the open issues and contribute a solution, go ahead. In addition to the administrators, the following developers are currently registered: Alain Danteny (adanteny) Armin Tüting (atueting) Chris Kohlert (ckohlert) David (david_g_wright) Erwin Lotter (elotter) hgx (hgx) Igor Epatko (wavesimsoft) Jayraj...
-
I tried the project, and looks like the OBJ files that are generated are 32-bit: first of all, they are created under the Debug folder and not under the x64/Debug where would be the natural location, and second, I run dumpbin /headers to examine the obj files and they are reported as 32-bit: FILE HEADER VALUES 14C machine (x86) So I dug into the vcxproj file and I fuond that the 64-bit condition sections looked like this: <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'"> <ExecutablePath>$(VC_ExecutablePath_x86);$(CommonExecutablePath);$(VCInstallDir)bin;$(WindowsSdkDir)bin\NETFX...
-
Hi Martin, Use the Examples and OWLNext Project Template for comparison. Use e.g. Notepad to inspect the nitty gritty details. Hopefully, you'll spot the issue. If not, ask AI for help. If you're still stuck after that, recreate the project file from scratch using the project template or an example.
-
Windows_Message_Dispatch_in_OWLNext
-
The above post was from me...but I neglected to log in before I posted it so it is Anonymous. Apologies for that.
-
Anonymous posted a comment on discussion Open Discussion
I have a simple x86 Windows template application written in C++ under Visual Studio 2022 using OWLNEXT 7. This works fine as an x86 application, but I have tried to modify the settings to build it as an x64 application with no success. I have changed the solution platform to x64 and the project platform to x64 and done a full clean. Everything compiles fine, but then I get the linker error Debug\INPUTDLG.obj : fatal error LNK1112: module machine type 'x86' conflicts with target machine type 'x64'....
-
Possible solutions to aliasing issues by @vattila 15:47, 19 March 2010 (UTC) A solution to the first aliasing issue (1) for the BI_NOTHUNK option requires TWindow to not only store a pointer to the original window procedure, but also a pointer to the window object that owns it, if any. The object pointer is needed to update the look-up table. This is unlike the thunking solution, where the window object pointer is part of the window procedure itself. A solution to the second issue (2) is harder....
-
@elotter wrote: However, [using using to try to circumvent the OWLNext requirement that event handlers must be defined in the class owning the response table] didn't work I'm not sure what is going on here; why you can compile it, but the code does unexpected things. It has the characteristics of a compiler bug. Have you tried making a test case you can explore with different compilers at Compiler Explorer? I presume you are fully aware of this (by stating that this was an attempt "out of curiosity"),...
-
branches/elotter-cooledit:
1 >