Thanks everyone for your thoughts/help. I feel more confident now going ahead with the upgrade.
jpyp
Thanks everyone for your thoughts/help. I feel more confident now going ahead with the upgrade.
jpyp
Yes it is a home grown MFC C++ application and we maintain it. I am more concern about the required level of effort to upgrade it to VC++ 2008. Thanks!
jpyp
Hi guys! My organisation has an application that is approximately 10 years old. It is not a Web application. It is supported by MS Visual Studio 6 and still runs mostly on Windows NT4 workstations and a few XP. They want to replace all NT4 computers with XPs and take the opportunity to upgrade our development environment also. Looking at the Microsoft site, I think that all we need is the Visual Studio 2008 Professional with MSDN Professional version. Is this a good plan and if it is, how hard is it to migrate to this new version? Thanks!
jpyp
I use Studio 6.0 and you are right it does not compile. I had taken out the initialization before in my code but forgot to take it out in my first post here. I understand now why it wasn't working initially. The size of the buffer must be the same as the value in the last field. I was providing a value of 0 for KeySize because I thought it was a output value only. So only one call is necessary but it is certainly safer to do it your way to get the actual size of the value. As for the wrong data types, I took those directly from the MSDN library help page. Their data type are LPDWORD for the key type and key size fields. Thanks a lot for your help!
jpyp
Yes it compiled without any errors/problems. I tried yours and it works but it brings up the following questions: Why do I need the first call to RegQueryValueEx? What does it do? Why does the first call fail when I provide a buffer instead of NULL? Thanks!
jpyp
Looks like the only way to get the new value is to read it from the registry. Using regedit I can see the new value under key HKEY_CURRENT_USER\\Environment\\SSSRights which has a value of "A". But there seems to be something wrong with my code becomes I always get a return value of 87 which apparently means ERROR_INVALID_PARAMETER when I call RegQueryValueEx(). hMyKey has a valid handle after call to RegOpenKeyEx(). Here is my code:
HKEY hMyKey;
long lResult;
LPDWORD pKeyType = REG_SZ;
LPDWORD pKeySize = 0;
char* strKeyName = "SSSRights";
char* strKeyVal = "\0";
RegOpenKeyEx(HKEY_CURRENT_USER, "Environment", 0, KEY_QUERY_VALUE, &hMyKey);
lResult = RegQueryValueEx(hMyKey, strKeyName, NULL, pKeyType, (LPBYTE)strKeyVal, pKeySize);
RegCloseKey(hMyKey);
jpyp
I created an environment variable using the Windows System Properties page. In my program I called getenv("varname") to retrieve the value of my environment variable. After changing the value of my variable, I can see the change when running my program from the desktop but I get the old value when running the program from within MS Vis C++ unless I restart Vis C++. Obviously Vis C++ reads the environment settings and uses them from that point on. Is there any way to "refresh" the environment from within Vic C++ so that the next time I run my program, it picks up the new value? Thanks!
jpyp
Hi! One of my include file used to be like this: my_include.h struct tagInfo { int a; int b; } stInfo;
Then I added the element c: struct tagInfo { int a; int b; int c; } stInfo;
My program goes something like this: #include "my_include.h" MyProg () { // somewhere in my code CString string1.Format("%d", stInfo.a); CString string2.Format("%d", stInfo.c); }
In the string#.Format statement, when I type the . after stInfo, VC++ open a popup window with a list of all elements included in the structure stInfo. That list still shows a and b only. The element c is not showed but it compiles properly. I know I have the right file because if I change the element a to z in my include file, then the code does not compile because a is not a member of stInfo. I guess I need to refresh something but I don't know what. Thanks for your help.
jpyp
I fixed it!!!!! But before I tell how I fixed it, let me answer your comments/questions. First I'll show how the dialog is designed: RadButCol1 RadButCol2 PushBut1 EditCol1_1 EditCol2_1 PushBut1 EditCol1_2 EditCol2_2 PushBut1 EditCol1_3 EditCol2_3 PushBut1 EditCol1_4 EditCol2_4 ... PushBut19 EditCol1_19 EditCol2_19 David: At design, I disable all buttons in column 1 and 2 and the two radio buttons are unchecked. So when I open the dialog both columns should be disabled. Then the user should clickone of the radio buttons to enable one set of edit controls. However when the dialog is open, the handler for RadButCol1 is being called automatically and therefore the edit controls of column one get enabled. Mark: Setting the first push-button as the default button did not help. Also I tried with calling SetFocus() in the OnInitDlg() on PushBut1 so that the RadButCol1 would not have the focus on startup, but that still did not work. Now the fix (and I still don't know why it worked!!!!): In my .rc file I moved the declarations of the two radio buttons down so that they are not first in the dialog definition. Being first seems to trigger a BN_CLICKED notification message for some reason. If you have any idea why, please let me know. I really appreciate your help and time on this issue. Thanks!
jpyp
I'll investigate the UpdateData() idea. See my last post to Mark with regard to more explanation on the problem. Thanks!
jpyp
I do get the same problem if I comment out the SetCheck call. I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know. The reason I worry so much about it is that I have other controls on this dialog that are supposed to be disabled when the dialog opens. When the user click on the button that I have problem with, these controls are then enabled. My problem is that when I receive this "irritating" message when the dialog opens, these controls get enabled when they should not be yet because the user has not click on it yet. Hope I'm making some sense. Thanks!
jpyp
Thanks for your reply. However this will not help as the handler is being called after OnInitDialog() completes so in OnButtonChange() m_bInitializing will always be FALSE. This is driving me crazy. This behavior does not happen with my other dialogs.
jpyp
Thanks for your reply and info. As I stated in my original post, the high word of wParam is 0. I still can't figure out where this message is coming from. This is driving me crazy. If you can think of anything else, please let me know. If not thanks anyway for your help.
jpyp
Got you! Thanks for the explanation. Now considering my answer to DavidCrow, what do you think could cause this message to be generated? As I previously said, I am not sending this message anywhere in my code. The call stack proves it and looks like this: Message handler ... (a number of DLL and OS functions) OnCommand ... (a number of DLL and OS functions) Function where I call Create() to create the dialog (stopped at the Create() call). Thanks!
jpyp
DavidCrow wrote:
While your code may not be doing it directly, a BM_SETCHECK message is being sent to the control, thus the control's handler is doing what it should. If this is undesirable behavior, there's an easy solution.
By easy solution you mean removing the SetCheck(FALSE) call in OnInitDialog(), I tried that with no difference. Any other suggestions? Thanks!
jpyp
Sorry but maybe I was not clear enough. I open this dialog window by clicking on a menu choice in my main window. When the dialog opens, OnInitDialog() completes then the handler of the radio-button, which is in the window just opened, is being called. I break in the handler and I move to the OnCommand function using the Context window of the debugger. Then I check the value of lParam and it changes everytime I close and reopen the dialog window using the menu choice of my main window. If what you say is true regarding lParam containing the handle of the control sending the message, then the value in lParam should always be the same because I am always using the menu choice to open the dialog window. Maybe I am missing something here! Thanks!
jpyp
I know I should be posting code snippet but my program is on a classified network. It is very difficult to transfer the code and I don't want to have to type everything needed here. So let's give it a try without the code snippet first. When I open one of my dialog window, one of my radio-button is being handled right away after OnInitDialog{} completes. In OnInitDialog() I call SetCheck(FALSE) for that particular button. And then after OnInitDialog() completes, my handler for that button is called by the framework without any of my code sending a message. I have checked the parameter values of the OnCommand function and they are as follows: 1. wParam low word contains the control ID of my radio-button. 2. wParam high word contains 0. 3. lParam low word contains a 4 digit number. This number changes every time I open the window. 3. lParam high word contains a 3 digit number. This number changes every time I open the window. The numbers in lParam do not relate whatsoever to the controls on my dialog. Also there is no way the message is being sent from somewhere else in my code. Where is this message coming from? Anybody has an idea? Thanks!
jpyp
Thanks that did the trick. However I don't understand why all my push-buttons IDs on that window are showing on the "Member Variables" tab as none of them except one has this property set. Furthermore my radio-buttons in my other windows do not have the WS_GROUP property set, and they are all showing on the "Member Variables" tab. Both windows have the same properties and are created the same way. Something else seems to be going here. Any idea? Thanks!
jpyp
I created a new dialog window that includes a number of push-buttons and radio-buttons. When I open ClassWizard I see all my IDs in the "Object IDs" list on the "Message Maps" tab. However on the "Member Variables" tab, some of the IDs are not showing in the "Control IDs" list. I have other dialog windows that are set up the same way and I don't have this problem. What can cause this? I am using MS VC6. Thanks!
jpyp
Thanks a lot to both of you for your advice. I will definitely take them under consideration when I move to high-rate transfers.
jpyp