You're right, it shouldn't but something is causing it. There is nothing in the code that resizes or moves any of the controls. The program was designed to be fixed position & size from the start.

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.

Yes. No change. Also tried "override high dpi scaling", with no change. Although at 1080p, there shouldn't be high dpi issues.

I've tried various scaling settings, and it doesn't help. It appears the controls inside the dialog windows are being drawn as fixed pixel dimension. The scaling settings only change the dimension of the window. So actually, if I set scaling to 200%, the dialog window becomes large enough to show all the controls within. But that's not an ideal solution, since 200% is almost unusable for everything else. What has me stumped is that other PCs of similar specs do not exhibit this issue.

no. they were designed in dialog editor.

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.

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.

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?

I am using VS6 also. I believe fefe.wyx meant using class wizard to assign a float variable to the edit control. Then it will be restricted to that type, and to retrieve data you can call UpdateData(true). But I can't use this method because of the reason in my above reply.

not quite sure what a masked edit control is. But reason I didnt fix the editbox to a certain datatype is because I reuse that editbox for several different inputs. Sometimes I want a float as in the example above. Sometimes I want HEX, in which case, I do error checking like so: if (1 == sscanf(ValueStr, "%X", ValueInt)) Sometimes I want int. etc... Which is why I kept input free from any restricted datatype, and handle input on a case by case basis.

So I am trying to take user input from an editbox for my dialog based app. The value should be a single float. I retrieve the value using GetWindowText() and sscanf(). I check that sscanf returns 1 to show that it in fact succesfully scanned in one CString ValueStr; float ValueFloat; GetDlgItem(IDC_EDITBOX)->GetWindowText(ValueStr); if (1 == sscanf(ValueStr, "%f", ValueFloat)) { //valid data, processing it... } else { MessageBox("Invalid input value."); } The problem is that this method of error checking is not the best. For example, if the user enters "20.5p", that will not flag an error, but instead will just take 20.5 as a valid value and ignore "p". How can I do more thorough error checking, such that I check to make sure the input is ONLY a single float and no trailing characters? Thanks

Im not using any. I'm only using the regular MFC dialog controls.

I get an initialization failure sometimes when I run my program. "The application failed to initialize properly (0xc0000142). Click on OK to terminate the application." What is 0xc0000142? Where can I find what it means? Once I get this error, its the same everytime I run it. Until I restart my computer, then everything works fine. Then at seemingly random times during development, I get this error again. And it wont go away until I restart.

DavidCrow wrote:

You're not out of luck just yet. Two plausible solutions still exist. One is to change the third parameter of ManageTasks() to include CModule. I don't have the syntax readily available, but it's not uncommon and can easily be searched.

Tried that, see by reply to Randor below. I will try the overloaded function way. However, one of the reason I wrote my code the way it is was so that I can easily add more functions later (ie FunctTask4,5,6 etc) without having to change much code. Just add a new case in the OnSelchangeCombobox function. I can still call ManageTask to do the same things. Having to overload every single one seems inefficient to me.

tried that, but when I call ptrFunct(0,0); from inside ManageTask, I get an error saying "term does not evaluate to a function". Edit: nevermind. just realized i have to call it like this: (this->*ptrFunct)(0,0); -- modified at 18:42 Thursday 1st November, 2007

In that case, I can't use it the way I had intended. I need FunctTask1,2,&3 to be able to access other member variables and functions that aren't static, so making it static wont work. Time to rethink. Thanks for the help.

so i have to specify in the argument list of 'ManageTasks' to expect a member function and not a regular function? How do I do that?

I'm trying to pass a pointer to a function as an argument to another function, but I am getting compile errors.

class CModule : public CDialog
{
// Construction
public:
CModule (CWnd* pParent = NULL); // standard constructor
...
private:
unsigned char FunctTask1(unsigned char, unsigned char);
unsigned char FunctTask2(unsigned char, unsigned char);
unsigned char FunctTask3(unsigned char, unsigned char);
void ManageTasks(unsigned char, unsigned char, unsigned char (*)(unsigned char, unsigned char));
};

unsigned char CModule ::FunctTask1(unsigned char Param1, unsigned char Param2)
{
...
}
unsigned char CModule ::FunctTask1(unsigned char Param1, unsigned char Param2)
{
...
}
unsigned char CModule ::FunctTask1(unsigned char Param1, unsigned char Param2)
{
...
}

void CModule ::ManageTasks(unsigned char Param1, unsigned char Param2, unsigned char (*ptrFunct)(unsigned char, unsigned char)
{
... //unrelated code removed

switch (ptrFunction(1,1))
{
case 0:
//handle results
case 1:
//handle results
}

... //unrelated code removed
}

now based on a combobox selection, I will call a different function

void CModule::OnSelchangeCombobox()
{
switch(m_Combobox->GetCurSel())
{
case 0: ManageTask(1,1,FunctTask1); break;
case 1: ManageTask(1,1,FunctTask2); break;
case 2: ManageTask(1,1,FunctTask3); break;
}
}

but i get this error on compile 'ManageTasks' : cannot convert parameter 3 from 'unsigned char (unsigned char,unsigned char)' to 'unsigned char (__cdec l *)(unsigned char,unsigned char)' What am I doing wrong? FYI I'm using VC++ 6.0.

I have two CArray objects. One is <WORD, WORD> Other is <float, float> I know there isn't a problem with that part of the declaration.

So the way I am using CArray is correct? Then the app crashing must be something else. Dam, back to square one. :sigh: