Click here to Skip to main content
14,691,238 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi,

This problem has me pulling my hair out?? I have an application that doesn't display text for some users. I cannot replicate the problem as it works fine for me. I did discover that if I run the application as an administrator the problem happens?

When running the application as an administrator the SetWindowText function does not work. When running the application as normal the SetWindowText works fine.

If I try to debug the application in Visual Studio 2017 running the application in admin mode it works fine so I cannot see what the problem is. I have displayed a message box just before it calls SetWindowText and the messabe box displays the text correctly but the SetWindowText is blank?

Here's an example of the test code.


// Declared in the Header file
WCHAR m_UserPrompt[128];



// CPP implementation file
void CUserPromptDlg::GetDisplayPrompt(WCHAR *pUserPrompt)
{
	wcscpy(pUserPrompt, L"Test message");
}


void CUserPromptDlg::TestFunc1()
{
	GetDisplayPrompt(m_UserPrompt);
	AfxMessageBox(m_UserPrompt);
	SetDlgItemTextW(IDS_USER_PROMPT, m_UserPrompt);
}


What I have tried:

I have tried everything I can think of but I cannot figure out why it works for 85% of users and not for the other 15%??
Posted
Updated 14-Apr-20 6:39am
Comments
KarstenK 14-Apr-20 9:51am
   
you missed to add the code for your SetWindowText bug!
MickFarrell 14-Apr-20 10:33am
   
Hi, it is included above, not sure why you can't see it but here it is

// Declared in the Header file
WCHAR m_UserPrompt[128];



// CPP implementation file
void CUserPromptDlg::GetDisplayPrompt(WCHAR *pUserPrompt)
{
wcscpy(pUserPrompt, L"Test message");
}


void CUserPromptDlg::TestFunc1()
{
GetDisplayPrompt(m_UserPrompt);
AfxMessageBox(m_UserPrompt);
SetDlgItemTextW(IDS_USER_PROMPT, m_UserPrompt);
}

Do your other 15% users use computer language configuration set to EN(US)?
   
Comments
MickFarrell 14-Apr-20 10:35am
   
Hi,

I will check with a couple of the users to see if they have different language setups on their PC's.

If it is a problem with language setups why would it happen to me when I run in Admin mode but not when I don't?
MickFarrell 14-Apr-20 11:49am
   
I checked with 4 users and they all have their language and regional settings set to EN(US). One of those users has the display issue
steveb 14-Apr-20 11:52am
   
Usually it would just display garbage characters if you place en(us) codes onto cyrillic or japanese langs. Also since you put the string, by what it looks like, the static text control, make sure it is wide enough. As far as I remember when static text does not fit the box it will remain blank. Unlike edit text box.

And most important: call UpdateData(FALSE) after if your m_UserPrompt bound to DDX_ routines updates
MickFarrell 14-Apr-20 12:23pm
   
Hi Steve, m_UserPrompt isn't bound to any DDX, it is just a WCHAR array with plenty of room. The text box in the dialog has plenty of room and displays the text prefectly when not run as an Administrator.
steveb 14-Apr-20 13:36pm
   
Ok. I am not an Admin on my machine. I just created dialog based app and used exactly your code (I called TestFunc1() from OnInitDialog). And it works fine whether I ran is as Admin or a regular user. There something else is missing in your code. I cannot tell what.

BTW since you using MFC you can use CString instead of WCHAR[128] and DDX_ bind it to the control. Call UpdateData(FALSE) after you change CString value. If you build UNICODE CString becomes CStringW.

Also I noticed this: Your control ID is IDS_USER_PROMPT. This maybe nothing. But MSVC app wizard uses prefix IDS_ for resource strings and prefix IDC_ for controls. Double check that your IDS_USER_PROMPT is not a "String Table Resource" but an actual control ID
MickFarrell 15-Apr-20 7:02am
   
All good points Steve, and yes the default is IDC_ I have tried adding a new edit control and left it at the default define IDC_EDIT and even the new edit control doesn't work. I'm pretty sure your suggestion would work, if I use the following code (added a CString) it works 100% of the time for all users:

void CUserPromptDlg::TestFunc1()
{
GetDisplayPrompt(m_UserPrompt);
CString temp = m_UserPrompt
SetDlgItemTextW(IDS_USER_PROMPT, temp);
}

I removed the AfxMessageBox(m_UserPrompt) as that is just for testing, it has no impact.

I think you may have been onto something with your previous question about the language and regional settings. We created a few new test accounts on Azure for some testers to test with.

Tester1 logs into Azure using an Azure user account "AzureTest1" and the text is missing.

Tester2 logs into the same Azure account "AzureTest1" and the text appears for him.

Tester1 used his second PC to log into Azure using the Azure account "AzureTest1" and the text appears.

It seems to be some how related to settings on a local PC been passed into the Azure account when logging in? They are checking local and regional settings to see if they can narrow it down

Thansk for your help and suggestions Steve!
I have had a similar problem with simple Messagebox calls, when the WM_PAINT handler does not call the BeginPaint / EndPaint sequence. You may like to check if that is a possibility.

[edit]
// CPP implementation file
void CUserPromptDlg::GetDisplayPrompt(WCHAR *pUserPrompt)
{
	wcscpy(pUserPrompt, L"Test message");
}


void CUserPromptDlg::TestFunc1()
{
	GetDisplayPrompt(m_UserPrompt);
	AfxMessageBox(m_UserPrompt);
	SetDlgItemTextW(IDS_USER_PROMPT, m_UserPrompt);
}


You appear to be using different variables for the text.

[/edit]
   
v3
Comments
MickFarrell 14-Apr-20 11:51am
   
Hi Richard,

I have simplified the code as much as possible to test and I only use the basic CDialog with no WM_PAINT message handling. The same code works fine but does not display text when run in Admin mode?
MickFarrell 14-Apr-20 11:51am
   
Hi Richard,

I have simplified the code as much as possible to test and I only use the basic CDialog with no WM_PAINT message handling. The same code works fine but does not display text when run in Admin mode?
Richard MacCutchan 14-Apr-20 11:57am
   
See my updated solution.
MickFarrell 14-Apr-20 12:16pm
   
Hi Richard, One is a pointer to the WCHAR array. m_UserPrompt is declared in the header file.

Solution 1: If I moved m_UserPrompt from the Header file and declare it in the class function TestFunc1() as a local variable it works fine.

Solution 2: If I copy the contents of m_UserPrompt to a CString it works fine.

This has me completely puzzled?? I'm convinced the problem is UNICODE related but I can't figure it out?
Richard MacCutchan 14-Apr-20 12:29pm
   
Sorry but there is far too much detail that we cannot see. If you need to move something from the header to the implementation file to make it work then your class definition must be incorrect. You need to go through all your code line by line to ensure that it is complete, and that you have not misdirected something.
MickFarrell 14-Apr-20 12:58pm
   
Hi Richard, In regard to your previous solution, what was missing? You said "You appear to be using different variables for the text" but its there in the code calling a function to set the text?

A problem in the header file would not cause the text to only work if running in Admin mode. Running in Admin mode is the only way "I" can replicate the problem, for some users it just happens as they run it normally

I really do appreciate your time, input and suggestions and I do believe the problem is deeper than the small sample of code I have provided but I'm hoping someone may have come across something similar in the past and could point me in another direction. :-)
Richard MacCutchan 14-Apr-20 13:19pm
   
Sorry, I mis-read the code. However, where is the declaration of m_UserPrompt?
MickFarrell 14-Apr-20 13:33pm
   
Hi Richard,

It is declared in the header file. I did include it in my original post.

// Declared in the Header file
WCHAR m_UserPrompt[128];
Richard MacCutchan 14-Apr-20 15:32pm
   
Sorry, but I am getting more confused. Your original question states that SetWindowText is not working at times. Your example is using SetDlgItemTextW which is not exactly the same thing. Also, you have only shown parts of your code. I think you need to start again with a new question, which shows the complete definition of your class (whether a Window or a Dialog) and those parts of the implementation that actually cause the problem.

Finally, you should be aware that SetDlgItemTextW should return false if it fails, at which point you need to call GetLastError to find out why. I am not saying that that is what is happening but it needs checking given your problem.
MickFarrell 15-Apr-20 4:27am
   
It is a unicode program so SetWindowText is SetWindowTextW. The SetWindowText (SetWindowTextW or SetWindowTextA) does not return a value. You're mixing up the win32 api ::SetWindowText (::SetWindowTextW or ::SetWindowTextA) which does return true or false.

You have givien me an idea, I will try calling the win32 version and see what it returns? thanks
Richard MacCutchan 15-Apr-20 4:37am
   
Sorry, I have not used MFC for years, and assumed (foolishly) they would do the same. I also noted Steveb's comment above, about the ID you are using in your call. Are you certain that IDS_USER_PROMPT is a valid dialog control identifier?
MickFarrell 15-Apr-20 6:51am
   
Hi Richard, I've check to make sure that the IDS_USER_PROMPT id is unique and I have even added a new Edit box to the dialog to test and the text still appears blank in the new Edit box as well.

I did try using ::SetWindowText and ::SetWindowTextW (::SetWindowTextA won't compile as its a UNICODE project) and they both return true even when they don't display the text.

I have some of the testers doing some extensive testing on Azure and we did find something very interesting.

Tester1 logs into Azure using an Azure user account "AzureTest1" and the text is missing.

Tester2 logs into the same Azure account "AzureTest1" and the text appears for him.

Tester1 used his second PC to log into Azure using the Azure account "AzureTest1" and the text appears.

It seems to be some how related to settings on a local PC been passed into the Azure account when logging in? They are checking local and regional settings to see if they can narrow it down

Again thanks Richard for your time and input, its always very good to get some other ideas.






Richard MacCutchan 15-Apr-20 7:48am
   
"check the IDS_USER_PROMPT id is unique"
We were more concerned whether that was actually the id of the control, or the id of a resource string.
MickFarrell 15-Apr-20 10:56am
   
Yes it is the ID of the actual edit control and not the ID of a resource string.
Richard MacCutchan 15-Apr-20 11:02am
   
I was pretty sure it had to be, otherwise it would probably never have worked. But anything and everything is worth checking in a situation like this.
MickFarrell 15-Apr-20 12:43pm
   
I agree, I'd rather double check than assume. We're going to roll back to the previous SDK's when the issue wasn't present and run some testing.

The whole project is made up of over 1 million lines of code with a mix of c, c++, clr, c#, .net, ASP.net and there's only about 10 places where this happens, and it only happens under very strange conditions that we haven't yet identified.

I do have a work around but I don't want to implement unless we really need to.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900