|
Thank you Richard, tried with GDI+ only with some changes, now, i am able to get the required output.
Regards,
Gopinath.
|
|
|
|
|
I'm working on an embedded ARM-project (STM32F) and I'm programming in C programming language and compiling with Eclipse/GCC. In the project there is TRACE functionality implemented that, if enabled, logs various things over UART using queues and DMA:
#define TRACE(grp, lvl, ...) traceToPrintStream(grp, __FILE__, __FUNCTION__, __LINE__, lvl, __VA_ARGS__) It can be used, e.g. like this:
TRACE("regCallbacks", T_D, "The user pressed the button");
TRACE("regCallbacks", T_D, "Write to reg %d. First written byte: 0x%X", regAddr, regValues[0]);I need a different trace that is not queued, does not use DMA and does not include the file name, function name and line number, but the other persons in this project do not agree to throw out the existing TRACE, so I need to make something in parallel. I want to be able to enable my TRACE in two ways, either by #defines:
#define ENABLE_USER_EVENTS_LOGGING
#define ENABLE_COMMUNICATOIN_BUS_LOGGING or by setting a varible during runtime:
Bool_t enableCommunicationBusLogging;
Bool_t enableUserEventsLogging; I need a different grouping (the grp parameter) than the others, so the example TRACEings above would have to be augmented with my grouping as well:
TRACE_EX("regCallbacks", USER_EVENTS, T_D, "The user pressed the button");
TRACE_EX("regCallbacks", COMMUNICATION_BUS, T_D, "Write to reg %d. First written byte: 0x%X", regAddr, regValues[0]);The rules I would like to apply are:
1. If my TRACE is enabled using the macros (hardcode enabled), then the other TRACE can not be used (hardcode disabled).
2. If my TRACE is not enabled using the macros, then both TRACEs can be enabled/disabled during runtime independently of each other. However, they are enabled per groups!
Does anybody know how I can solve this? I found a great website (C Preprocessor tricks, tips, and idioms · pfultz2/Cloak Wiki · GitHub[^]) that shows some really neat macro-tricks, but I'm not sure how to apply it my case.
|
|
|
|
|
As I understand it (assuming the traceToPrintStream function is fixed) you need a slightly different macro for your TRACE_EX, something like:
#define TRACE_EX(grp, lvl, ...) traceToPrintStream(grp, "", "", 0, lvl, __VA_ARGS__)
If you want to enable the traces at runtime then you need them always enabled at compile time, otherwise you will need to rebuild the code every time. So to allow the traces to be based on switches you need something like:
#define TRACE_EX(switch, grp, lvl, ...) \
if (switch) \
{ \
traceToPrintStream(grp, "", "", 0, lvl, __VA_ARGS) \
}
where switch is the name of the boolean that controls the tracing.
|
|
|
|
|
Ok, so this is what I have now:
#define USER_EVENTS_LOGGING 0x00000001
#define COMMUNICATOIN_BUS_LOGGING 0x00000002
uint32_t enabledMyGrpBitFlags = 0;
#if defined(ENABLE_USER_EVENTS_LOGGING)
#define TRACE_EX(grp, myGrp, lvl, ...) if (myGrp & USER_EVENTS_LOGGING) printf_(__VA_ARGS__)
#elif defined(ENABLE_COMMUNICATOIN_BUS_LOGGING)
#define TRACE_EX(grp, myGrp, lvl, ...) if (myGrp & COMMUNICATOIN_BUS_LOGGING) printf_(__VA_ARGS__)
#else
#define TRACE_EX(grp, myGrp, lvl, ...) \
do { \
if (myGrp & enabledMyGrpBitFlags) { \
printf_(__VA_ARGS__); \
} \
traceToPrintStream(grp, __FILE__, __FUNCTION__, __LINE__, lvl, __VA_ARGS__); \
} while (0)
#endifIs it possible to remove the run-time checks:
if (myGrp & USER_EVENTS_LOGGING)
if (myGrp & COMMUNICATOIN_BUS_LOGGING) so that the TRACE_EX macro would become empty when the myGrop isn't matching? In other words, let's say only ENABLE_USER_EVENTS_LOGGING (not ENABLE_COMMUNICATOIN_BUS_LOGGING) is defined, then I would like the following line to "disappear" after the preprocessor is finished:
TRACE_EX("regCallbacks", COMMUNICATION_BUS, T_D, "Write to reg %d. First written byte: 0x%X", regAddr, regValues[0]);Is that possible somehow?
|
|
|
|
|
The run time checks are only effective at the time the code runs, so there is no way that the macro can be changed at that point. And the macro itself is evaluated, and its code generated in the preprocessor, long before the code is running.
|
|
|
|
|
I want to be able to compile in 2 different modes:
1. Normal mode: The 2 types of TRACE can be enabled/disabled during runtime independently of each other.
2. Hardcoded my TRACE only mode: Only my TRACE is enabled (1 or more myGrp TRACE groups), it's impossible to enable/disable anything TRACE related during runtime.
So, when compiling in mode 2 above, it should be possible for the macro to evaluate the passed myGrp parameter to determine how the TRACE_EX should be expanded. So if we only enable
#define ENABLE_USER_EVENTS_LOGGING then the preprocessor should be able to determine that this line should be removed:
TRACE_EX("regCallbacks", COMMUNICATION_BUS, T_D, "Write to reg %d. First written byte: 0x%X", regAddr, regValues[0]);
|
|
|
|
|
I have tried what I think you are asking for but the preprocessor rejects it. As far as I know you can only do it the way I already suggested.
|
|
|
|
|
On the following webpage C Preprocessor tricks, tips, and idioms · pfultz2/Cloak Wiki · GitHub[^] it is shown how an IIF (immediate if) statement for macros can be implemented. But as soon as I pass an expression, as oppose to either 0 or 1, to it, I can't get it to compile either:
#define USER_EVENTS_LOGGING 0x00000001
#define COMMUNICATION_BUS_LOGGING 0x00000002
#if defined(ENABLE_USER_EVENTS_LOGGING) && defined(ENABLE_COMMUNICATION_BUS_LOGGING)
#define HARDCODE_ENABLED_MY_GRP_BIT_FLAGS (USER_EVENTS_LOGGING | COMMUNICATION_BUS_LOGGING)
#elif !defined(ENABLE_USER_EVENTS_LOGGING) && defined(ENABLE_COMMUNICATION_BUS_LOGGING)
#define HARDCODE_ENABLED_MY_GRP_BIT_FLAGS (COMMUNICATION_BUS_LOGGING)
#elif defined(ENABLE_USER_EVENTS_LOGGING) && !defined(ENABLE_COMMUNICATION_BUS_LOGGING)
#define HARDCODE_ENABLED_MY_GRP_BIT_FLAGS (USER_EVENTS_LOGGING)
#else
#define HARDCODE_ENABLED_MY_GRP_BIT_FLAGS (0)
#endif
IIF(1)(true, false) IIF((0 < (HARDCODE_ENABLED_MY_GRP_BIT_FLAGS & USER_EVENTS_LOGGING)))(true, false)
|
|
|
|
|
Sorry, that is something I have never seen before. To be honest I think you are in danger of making things far more difficult than you need. The original spec I suggested where you can generate (or not) the macro that includes a runtime check, is the simplest way of doing it.
|
|
|
|
|
Hi all,
Is there an easy way to save the current CMFCpropertyPage number when closing a CMFCPropertySheet so that it can be reopened on that page. It seems that this is not implemented by default.
|
|
|
|
|
Just save the active page index in registry before closing.
Then read it from registry before activating and set the active page.
|
|
|
|
|
Non-modal ActiveX Control， a self-draw CMyTreeCtrl is shown on it.
Now, I create a CMFCToolTipCtrl in my CMyTreeCtrl and I want to dynamically change the text color of Tooltip.
I use SetParams in the ToolTip callback function and set new color/text .
However, I can't get new color when the tooltip displayed.
After I debug and found that it can't enter CMFCToolTipCtrl onPaint. If I use invalidate, then the whole ActiveX Control will flash rapidly.
I inherited CMFCToolTipCtrl and found that WM_PAINT cannot be received in PreTranslateMessage.
It can only receive WM_TIMER. Any other functions in afxtooltipctrl.h are not entered when the tooltip is shown.
And CMyTreeCtrl can receive WM_PAINT.
Could you help me find the reasion? Thanks a lot.
|
|
|
|
|
Hi,
Are you creating the CMFCToolTipCtrl with the TTF_SUBCLASS flag[^]? If so then you should be able to capture the NM_CUSTOMDRAW message[^] and check for the CDDS_PREPAINT draw stage. You can use SetTextColor[^] to change the text color from there.
Best Wishes,
-David Delaune
|
|
|
|
|
Member 14882671 wrote: I use SetParams in the ToolTip callback function and set new color/text .
However, I can't get new color when the tooltip displayed.
After I debug and found that it can't enter CMFCToolTipCtrl onPaint. If I use invalidate, then the whole ActiveX Control will flash rapidly.
I inherited CMFCToolTipCtrl and found that WM_PAINT cannot be received
There are virtual methods you could use to customize CMFCToolTipCtrl:
CMFCToolTipCtrl Class | Microsoft Docs
and some other OnDraw... methods.
|
|
|
|
|
I have an old MFC Dialog Based app that was designed in the WinXP and Win7 era. This project is for internal use and no longer in development. In Win10, we have scaling issues with high DPI screens (some controls are small or positions compressed), which is to be expected. However, on standard DPI screens, there have not been any issues until now.
One user reports that the dialog window is correctly sized (fixed sized), but all the controls within the window are scaled up beyond the boundaries of the dialog window and so half the controls are hidden. Display scaling settings in windows is normal (100%). What could be causing this?
|
|
|
|
|
How hard could it be for Visual Studio (new or recent or even old versions for that matter) to convert this old MFC Dialog-based application?
If it could convert this old MFC Dialog-based application it will. If it can't then attempting to open it's project files will result in a telling error message which, of course, will be useful to the learned helpers here on CP.
Try posting that message.
|
|
|
|
|
Can you clarify convert to what?
I can open the project in Visual Studio 2019 without issues after installing the older toolsets. I do need to maintain compatibility with WinXP. There are some computers that are still running WinXP due to old software/hardware compatibility.
I'm not sure if the UI issue is related to MFC. Converting to .NET forms would not be a simple task.
|
|
|
|
|
If you have a business process that is still running on Windows XP, you have MUCH BIGGER problems than this MFC code.
The hardware does not last forever, and when (not if!) it fails, then what? What are you going to replace a bad motherboard with? Or this "old hardware"? What happens when that fails? Hardware that old isn't made any more and good luck trying to find someone to fix it.
Modern day machines will not run Windows XP. Hell, nowadays, Windows 10, or a modern equivalent is required!
Your process is teetering on the brink of failure.
|
|
|
|
|
I completely agree with you. However, that's a business decision that is out of my hands. We use this to support older equipment. Our customers don't want to pay the significant upgrade to our latest equipment, and our bosses don't want to lose the repair/maintenance business. A lot of industrial equipment (not just ours) that don't connect to the web still run on XP. A surprise for me when I first started, but true nonetheless.
|
|
|
|
|
I hear that.
Customers are prone to screwing themselves.
|
|
|
|
|
So if you're talking about WinXP 32-bit (there was actually a time when one who licensed this had an opportunity to acquire the 64-bit installation disks believe it or not) or if you were indeed one of those paying attention to the offer to get that 64-bit version and had machines that could run 64-bit OS and successfully got it up and running (just before Windows Vista 32 & 64 bit made it evident that the future was going to be 64-bit and hyperthreaded as well) you are probably also aware that once Windows 2000 was supersceded, no 16-bit programs were allowed to run anymore.
And since you suggest VS2019 will open this application and you're not telling me about the previously mentioned flags during conversion I'd say you're good to go to set the project build targets to whatever is available and test a compilation.
Next moves:
1. Move some controls around and recompile.
2. Re-reference "missing" assemblies (or COM objects/whatever) and if not able to do that try what you suggest, substitute .NET interops (sometimes that works).
3. Sift through the compile/link errors (I'm finding it hard to believe that you've opened this thing without any conversio notices actually) ... use VERBOSE; note what crops up as documented error or warning.
And finally, since this is clearly a hardware issue for you (which I also doubt has anything to do with MFC of any flavor of MS Windows), try hooking up a less resolute monitor.
Graphics card you ask. Also doubtful. MFC is MFC is MFC (it's VS that fronts the eminence)
|
|
|
|
|
The winxp issue is out of my control unfortunately. A few PCs must run xp (due to software/hardware unrelated to this MFC app in question), the rest are win7 and 10. Therefore, this MFC app need to run on all if possible.
Sorry, I misunderstood when you asked for errors. Thought you meant compile errors, of which there were none after changing some flags. The flags were:
1>cl : Command line warning D9035: option 'Gm' has been deprecated and will be removed in a future release
1>cl : Command line error D8016: '/ZI' and '/Gy-' command-line options are incompatible
I fixed by changing /ZI to /Zi. Then it compiled without errors.
I also changed platform toolset to "Visual Studio 2017 - Windows XP (v141_xp)" from "Visual Studio 2010 (v100)".
I couldn't find the verbose option in Project Properties. Where can I find the verbose option? I did increase the Warning Level from 1 to 4. Is that what you mean? I'm getting lots of warnings now that seem to relate to converting from MSVC to ISO C++ 14. I will have to work through them all.
There are no COM objects used in this project.
Regarding hardware/graphics card issue, I thought MFC abstracts hardware layer away? As you said, MFC is MFC. I got to spend a few minutes on that laptop today. It's a dell with integrated graphics and 1080p screen. Other laptops with similar specs have been able to run this program normally, which is why I suspected some setting on this PC. If I set the system level scaling to 200%, the dialog app window is enlarged accordingly such that you can now see all controls. Almost as if the controls in the dialog window are fixed dimension, and the system scaling only applies to the box around it.
Thanks for the help and pointers.
|
|
|
|
|
OK!
Good signs then: the (project .. I was guessing) compiles. And it's important that you provide information like what the version you migrated from -> VS 2010 to VS 2017. That type of thing is always helpful for those trying to help. I haven't upgraded since 2010 and am sticking to my 64-bit guns still (not until MS, not until).
VERBOSE is a linker switch and what it does is make ALL linker messages present in the immediate window (yes, there's the overly warning/error widget which modernized the whole business) which I find easier to interpret mainly because it's time sequential and spits out mangled strings that can be used in a regular file search through your system; in the event that any one error says a library is missing, you can just type in the string that "can't be found" and window's search'll usually tell you which library to add to the reference (it contains the stubb of the string).
But since you've more or less passed over that hurdle and the thing's essentially a .dll or .exe or a set of each or both you can skip that.
I just have only one more thing to add and that's as I said ... MFC is more or less pushed by the VS version you've produced your executables with and as targetted OS .exe and .dll, managed or otherwise (I'm lumping .NET in this statment as well as long as you've properly dialed in the assembly in the properties (3.0, 3.5 ... what are we up to now? 4.5? etc) [as well I mean]) and as to why if you were building under x86 (for Win7 say or even WinXP) how anything out of even VS2017 would cause scale and panel metrics to be out of whack I can't fathom. As you say "abstracts in the hardware layer" ... bad stuff all wrastled out by informed folk at NVidia/etc.
I see in some of these posts that "Advanced Settings" has been a topic but I can say that unless this is an old video game you're trying to spruce up enough to display the same interface you had on 1080 (not even right?) 1200 x 1600 multimonitor set up while running @ 600 x 800 ... that'd be the only place to do the appropriate experimentation. Sometimes that battle can be won but I've lost it more times than I care to count.
Try everything? Sorry I can't be of more/better help.
|
|
|
|
|
Have you tried running the app in compatibility mode?
|
|
|
|
|
Yes. No change. Also tried "override high dpi scaling", with no change. Although at 1080p, there shouldn't be high dpi issues.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
