C / C++ / MFC

Jim Crafton10-Dec-04 6:36

Jim Crafton

10-Dec-04 6:36

You might consider using Spy++ to display the dialog and then get info on the control in question - this will give you the control's ID, which you could then use with the GetDlgItem() call, passing in the ID that Spy++ discovered.

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

SELECT * FROM User WHERE Clue > 0
0 rows returned

mayoung10-Dec-04 6:49

10-Dec-04 6:49

Hi Jim,

Thanks for the quick reply. I think the problem is with getting a handle to the actual dialog on which the control is drawn. I have to pass this handle (I believe) to the GetDltItem() function. I have tried both the hdlg parameter, and GetParent(hdlg) in the hook function, but neither one seems to work. I have been looking at Spy++, and the handle I get for the actual dialog does not match either one of these...

I will look at it again, though. Thanks.

bolivar12314-Dec-04 7:23

bolivar123

14-Dec-04 7:23

Since you're using MFC (or it appears so), it might be a little easier if you subclass CFileDialog and overload it's OnInitDialog member function. In the subclass OnInitDialog function, you can use GetDlgItem(), using the control IDs that you obtain using Spy++, to get pointers to the dialog controls you want to hide.

If you do this way, you won't need a special dialog proc and you won't have to deal with the OPENFILENAME structure.

mayoung16-Dec-04 5:11

16-Dec-04 5:11

Yes, thank you. I had originally tried doing this, but was unable to get handles to the controls on the dialog. I was using the constants defined in dlgs.h (edt1) to grab handles (GetDlgItem()). Are these constants not correct? I'm confused as to why I would need to use spy++ to get the ids...are they not constant?

Thanks for all the help.

mayoung16-Dec-04 6:11

16-Dec-04 6:11

Okay, I tried this, and there are two problems (unless I'm doing something wrong). The first is, spy++ gives me handles to windows, not control id's. The second is, these handles are not constant...they are different each time I bring up the dialog box.

bolivar12316-Dec-04 9:25

bolivar123

16-Dec-04 9:25

Yes, you are correct, the window handles will most likely be different each time the dialog comes up. Here's a step by step in Spy++ to get the info you need.

1. Bring up the common dialog having the control you want to hide. Do this before you run Spy++.
2. Run Spy++ and press Alt-F3 (Search for window).
3. On the Find Window, there's a crosshair icon, grab it and drag to the control on the common dialog you want info about. If you need to, you can check the "Hide Spy++" checkbox to get Spy++ out of the way. This will show the Handle and class name. Sounds like you got this far.
4. Now, click on the Ok button on the Find window dialog (in Spy++). The window you're wanting info about should now be selected in the tree view on the "Windows 1" view.
5. Right click on the highlighted item in the tree and select properties. This will bring up another dialog with the information that you need, namely the control ID.

Note that the Control ID is displayed in hex.

Given the Control ID, you can do something like this in your subclass OnInitDialog (example hides the Cancel button):

CWnd* pCancelBtn = GetDlgItem(0x0002);
if (pCancelBtn != NULL)
pCancelBtn->ShowWindow(SW_HIDE);

mayoung16-Dec-04 10:54

Problems with app icon and TaskManager

16-Dec-04 10:54

Thank you so much for the help. You've lead me in the right direction. The problem was in calling the GetDltItem...I needed to call that for the parent window:

CWnd *theParentWnd = this->GetParent();
CWnd *theEditBox;

// edt1 is defined in <dlgs.h>
theEditBox = theParentWnd->GetDlgItem(edt1);

theEditBox->ShowWindow(SW_HIDE);
This worked! By the way, the ID in spy++ matched that defined in dlgs.h, so I just used it.

Thanks again...whew, what a workout! Smile | :)

Jim Crafton10-Dec-04 5:47

Jim Crafton

10-Dec-04 5:47

I seem to be running afoul of the TaskManager in some way that I am unaware of.
In the VCF we have the core GUI library that contains an .ICO file that's used in the WNDCLASSEXW struct before calling RegisterClassExW().
I fill it in like so:

WNDCLASSEXW wcex;

wcex.cbSize = sizeof(wcex);

wcex.style = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS;
wcex.lpfnWndProc = (WNDPROC)wndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = (HINSTANCE)::GetModuleHandle(NULL);
wcex.hIcon = LoadIconW( Win32ToolKit::getInstanceHandle(), L"DefaultVCFIcon" );
wcex.hCursor= NULL;//LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszMenuName = NULL;
wcex.lpszClassName = className.c_str();
wcex.hIconSm = NULL;

This works fine. But sometimes when I call up the TaskManager there is no entry for the executable!. Using Alt+Tab, the window icon is there just fine.
It shows in the task bar just fine.

If I change the window icon dynamically by calling
HICON winIcon = //get the HICON image
SetClassLong (hwnd_, GCL_HICON, (LONG)winIcon);

Is this incorrect? Using WM_SETICON seemed to have problems as well.

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

SELECT * FROM User WHERE Clue > 0
0 rows returned

Warnings C4663, C4018, C4100

Robert Valentino10-Dec-04 5:03

Robert Valentino

10-Dec-04 5:03

Hello:

I needed to have an Animated Gif in my program so I included the code from PictureEx which works great except for the following.

I complie using Level 4 which means I get a lot of warnings.
Since including the code from PictureEx I now get 35 warnings for C4663, C4018 and C4100 these all refer to where he is using a Vector template class.

I tried using #pragma warning( disable : 4018 4100 4663 ) but this doesn't help. Tried all forms of this #pragrma and still can't get rid of these warnings.

I never have warnings in my code and can't figure out how to get rid of these that the PictureEx code has caused.

Can anyone help

Thanks

BobVal

Antti Keskinen10-Dec-04 5:42

Antti Keskinen

10-Dec-04 5:42

C4663 is caused by an old template class declaration. It is not an actual error, and should not cause errorneous behaviour, but when time goes on and new compilers appear, this declaration form will soon become a syntactical error. The creator of the class should alter the original source code to fix this. You can do nothing (besides directly modifying the source code) to fix it. If the source code license allows it, feel free to do it and post a corrected version to the author.

C4018 is caused by signed/unsigned comparison mismatch. This originally inherits from the way signed and unsigned numbers are handled. In assembly/machine-code, the concept of signed/unsigned does not exist. All numbers are unsigned there. The difference is made by interpreting the value. Consider an 8-bit value (such as a 'char'). If it is a signed char, direct values 0-127 refer to signed values 1...127 and values 128-255 refer to -128...0. It cannot have a value outside of range -128...127. A comparison operation in assembly is a mathematical substraction. If the substraction causes a 'borrow' to happen (don't know the actual math term in english for it), a flag is set. Looking at this flag, the conclusion of greater or not is made, and true/false is returned. It is possible that sometimes, when the numbers are suitable, an errorneous interpretation is made. I cannot outright remember what these conditions are. Lets just say that avoid comparing unsigned and signed numbers whenever possible Smile | :)

C4100 is caused by having an unreferenced parameter in function declaration. This is like having a needed parameter passed to a function and the parameter is never used inside the function, making it irrelevant for the function. It is most obviously a typing error in the source code. Fixing it requires checking the function in question and seeing if a parameter truly is unreferenced, and if it is, removing it from the function definition. Again, a source code change is necessary.

In conclusion, there's nothing you can do to fix these errors without altering the PictureEx source code. But none of them are critical, either, excluding the first one. C4663 might cause an error later on when a new compiler is released that no longer supports the old-style syntax.

Hope this helps.

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Member 89747210-Dec-04 7:45

Member 897472

10-Dec-04 7:45

THIS WAS ZERO HELP

I KNEW THESE ARE WARNINGS, I Stated this.

I know what the messages mean, I looked them up.

I WANT TO STOP the compiler from generating these warnings.

With the exception of this PictureEx code I have ZERO warnings when I compile my programs. I don't want to fix Microsoft's Vector template class and I don't know how to fix the PictureEx code to get rid of this warnings.

So I have been trying to get the complier to NOT DISPLAY them or IGNORE them when compiling the code.

Robert Valentino10-Dec-04 8:23

Robert Valentino

10-Dec-04 8:23

All these warnings are coming from Microsoft's templates VECTOR and XMEMORY

I just made the proper changes to them and saved a copy in my local include directory.

At least now I am back to ZERO errors, and maybe some day Mircosoft will release new templates.

Antti Keskinen10-Dec-04 9:41

Antti Keskinen

10-Dec-04 9:41

A simple 'no this did not help' would've been adequate. But no matter. You got the problem fixed, so no need for any of this anymore Smile | :)

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.