mfc, vs2022 compatible?
-
Maybe someone can point me to a reference or provide direct experience. I'm trying to lift a VC6++ application to VS2022. Originally targeted at Xp, this will need to run under Win10 and 11. So, I thought it would also be a good idea to get it into a modern development environment. Well, the # of warnings I am suppressing is getting concerning, but I understand what the warnings are about. Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Maybe someone can point me to a reference or provide direct experience. I'm trying to lift a VC6++ application to VS2022. Originally targeted at Xp, this will need to run under Win10 and 11. So, I thought it would also be a good idea to get it into a modern development environment. Well, the # of warnings I am suppressing is getting concerning, but I understand what the warnings are about. Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast<void (ccmdtarget::*)(nmhdr*,="" lresult*)=""> (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
1. It's not a compiler but IntelliSense alarm. 2. Yes, you are just wasting your time here. Just don't worry if the real compiling doe not show it as an error.
-
charlieg wrote:
Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast<void (ccmdtarget::*)(nmhdr*,="" lresult*)=""> (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
1. It's not a compiler but IntelliSense alarm. 2. Yes, you are just wasting your time here. Just don't worry if the real compiling doe not show it as an error.
-
Maybe someone can point me to a reference or provide direct experience. I'm trying to lift a VC6++ application to VS2022. Originally targeted at Xp, this will need to run under Win10 and 11. So, I thought it would also be a good idea to get it into a modern development environment. Well, the # of warnings I am suppressing is getting concerning, but I understand what the warnings are about. Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
"Waste of time"? If you're having fun doing this I'd say it's never a waste of time (doing this). That said, I'm reading WORD and thinking "If I ever get back into developing that QBASIC code (of mine) in that project in C++ where I've already got executable stubbs of function tests (vastly complex mathematical calculations made in lengthy formulas (astronomical in the sense of astronomy itself)) pasted into the VS interface, line numbers included (before QBASIC includes!), I'll probably have to go through MFC VC6++ in the stackoverload and codeguru websites to do the conversions and encounter this very issue". Do you mean DWORD? I think I get "0U" ... ;) I'll fire up VS now, sir ... (firing up vs now) ... "C26454" ... uhm ... hangon ...
-
"Waste of time"? If you're having fun doing this I'd say it's never a waste of time (doing this). That said, I'm reading WORD and thinking "If I ever get back into developing that QBASIC code (of mine) in that project in C++ where I've already got executable stubbs of function tests (vastly complex mathematical calculations made in lengthy formulas (astronomical in the sense of astronomy itself)) pasted into the VS interface, line numbers included (before QBASIC includes!), I'll probably have to go through MFC VC6++ in the stackoverload and codeguru websites to do the conversions and encounter this very issue". Do you mean DWORD? I think I get "0U" ... ;) I'll fire up VS now, sir ... (firing up vs now) ... "C26454" ... uhm ... hangon ...
I think something was mangled in the translation. I took: "Yes, you are just wasting your time here. Just don't worry if the real compiling does not show it as an error." which I took to mean not fret about the warning. I really need to lift this code, and working with VS2022 is "interesting." I've never seen a compiler generate so many arcane errors due to a typo. At the moment, I am trying to figure out why VS2022 is upset with '_messageEntries': const object must be initialized. It really has nothing to do with _messageEntries (this is an MFC thing) but more to with an error a few lines up.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I think something was mangled in the translation. I took: "Yes, you are just wasting your time here. Just don't worry if the real compiling does not show it as an error." which I took to mean not fret about the warning. I really need to lift this code, and working with VS2022 is "interesting." I've never seen a compiler generate so many arcane errors due to a typo. At the moment, I am trying to figure out why VS2022 is upset with '_messageEntries': const object must be initialized. It really has nothing to do with _messageEntries (this is an MFC thing) but more to with an error a few lines up.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Ok, sorry about that. I just stoked up VS2022 and looking in the help found the WORD initializer. Who knew? Although I guess I was on a "Joan of Arcadia" type of bender in my sarcastic musing, I've since settled on refraining from CP commenting for my own good and am turning over this new leaf by announcing it here in the C/C++/MFC forum where there's probably less of an iota of confusion not of my own making. Tyll should be good. Again, sorry.
-
Maybe someone can point me to a reference or provide direct experience. I'm trying to lift a VC6++ application to VS2022. Originally targeted at Xp, this will need to run under Win10 and 11. So, I thought it would also be a good idea to get it into a modern development environment. Well, the # of warnings I am suppressing is getting concerning, but I understand what the warnings are about. Then I ran into this line of code: "ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomDraw)" pure mfc macro which generates "....cpp(66): warning C26454: Arithmetic overflow: '-' operation produces a negative unsigned result at compile time (io.5)." Mousing over the macro, it expands to some hideous expression: "{ 0x004E + 0xBC00, (WORD)(int)((0U - 0U) - 12), 0, 0, AfxSigNotify_v, (AFX_PMSG)(static_cast (OnCustomDraw)) }," It's clear why the compiler is alarmed: "(WORD)(int)((0U - 0U) - 12)" Am I just wasting my time here? I'm going to thunder on, but I'm starting to wonder if I'm going to run into so much nonsense like this that it calls into question if I'll have anything working at the end....
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
it's been a loooonnnggg time since I converted/upgraded a MFC application. If I remember correctly, signature changed for a lot of MFC messages and callback functions. you need to check the documentation for each of those messages.
CI/CD = Continuous Impediment/Continuous Despair
-
it's been a loooonnnggg time since I converted/upgraded a MFC application. If I remember correctly, signature changed for a lot of MFC messages and callback functions. you need to check the documentation for each of those messages.
CI/CD = Continuous Impediment/Continuous Despair
tracked down the one thing that was plaguing me. Documentation? f***, all I can find are useless Microsoft help articles that are just informational to the point of flying you into the mountain. Return me to the days of DEC, where one bookcase help the complete knowledge.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
tracked down the one thing that was plaguing me. Documentation? f***, all I can find are useless Microsoft help articles that are just informational to the point of flying you into the mountain. Return me to the days of DEC, where one bookcase help the complete knowledge.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
:laugh: well, you can just read the header files.
CI/CD = Continuous Impediment/Continuous Despair
-
:laugh: well, you can just read the header files.
CI/CD = Continuous Impediment/Continuous Despair
lol, true. But going into the mfc afx, etc header files where "those people" took macros to an art form (I'm being generous) is tedious.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.