Re: The entry point GetFileVersionInfoSizeEx - C / C++ / MFC Discussion Boards

What happens to your HBITMAP variable when the function returns?

This is what I did.

C++

CString strFileName = _T("All_The_Path\\Resources\\quaid.bmp");
bitmap[0] = ::LoadBitmapW(NULL, strFileName);

But I should have done this.

C++

CString strFileName = _T("All_The_Path\\Resources\\quaid.bmp");
bitmap[0] = (HBITMAP)::LoadImage(NULL, strFileName, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION);

Thanks for your time.

This world is going to explode due to international politics, SOON.

Yeah, but what SandipG was getting at is you have a memory leak - you load both images each time the button gets pressed.

You're better off making HBITMAP bitmap[2]; a member variable of the dialog instead of local variables in the button press-code. Then you load both images in OnInitDialog.
In the button-press handler you work out which image to display then display it.

That way, you only call LoadImage once per image. Smile | :)

Thanks for this useful tip.

This world is going to explode due to international politics, SOON.

I was working in Windows Vista, and I moved the project over to XP to create the setup and deployment program.

I guess on the XP, I have some small details to fix. At first I thought it was just a Vista thing, I looked up the function, at it is Vista and up.

Not sure how to proceed on this, looking for suggestions.

Is there a way to use the ex and non ex version of the function, and to somehow keep them seperate?

You can check the version of the OS, and for XP, use the non-ex version.

Then for Vista and above, use GetProcAddress()[^] to dynamically link to the ex version at run time.

The difficult we do right away...
...the impossible takes slightly longer.

oh, so thats how you do it.

Thanks Richard

Actually is not as easy as it looks.
Unless you really need to retrieve localized version info size, use GetFileVersionInfoSize instead GetFileVersionInfoSizeEx. GetFileVersionInfoSize is available starting with Windows 2000. You do not have to call LoadLibrary and GetProcAddress since your module (exe) is linked implicitly with Version.lib.

To write robust code you would have to write more than simple GetProcAddress.
If you really want to use both, depending on the operating system, you will have to retrieve proc address depending on OS version and load appropriate procedure address, since Version.lib contains both: ASCII and UNICODE versions of the functions.
If your app is built as ANSII you would have to use ANSI version of the function: GetFileVersionInfoSizeExW or GetFileVersionInfoSizeW depending on what system your app is running on.
For unicode build you will have to explicitly request UNICODE versions: GetFileVersionInfoSizeExW or GetFileVersionInfoSizeA.
Something like this:

C++

//#define _USE_EXPLICIT
void GetFileVersionLenInfo()
{
	OSVERSIONINFO osvi = {sizeof(OSVERSIONINFO)};
	DWORD dwHandle = 8000;
	DWORD dwVer = 0;
	GetVersionEx(&osvi);
	HINSTANCE hInst = NULL;

#ifdef _USE_EXPLICIT

	typedef DWORD (CALLBACK* lpfnGETFILEVERSIONINFOSIZEEX)(DWORD, LPCTSTR, LPDWORD);
	typedef DWORD (CALLBACK* lpfnGETFILEVERSIONINFOSIZE)(LPCTSTR, LPDWORD);
	//typedef UINT (CALLBACK* LPFNDLLFUNC1)(DWORD,UINT);

	hInst = LoadLibrary(_T("VERSION.dll"));

	if(osvi.dwMajorVersion > 5)
	{
#ifdef UNICODE
		lpfnGETFILEVERSIONINFOSIZEEX lpfnGetFileVersionInfoSizeEx = (lpfnGETFILEVERSIONINFOSIZEEX)GetProcAddress(hInst, "GetFileVersionInfoSizeExW");
#else  
		lpfnGETFILEVERSIONINFOSIZEEX lpfnGetFileVersionInfoSizeEx = (lpfnGETFILEVERSIONINFOSIZEEX)GetProcAddress(hInst, "GetFileVersionInfoSizeExA");
#endif //  UNICODE

		dwVer = lpfnGetFileVersionInfoSizeEx(FILE_VER_GET_NEUTRAL, 
			_T("C:\\Program Files\\Beyond Compare 2\\BC2.exe"),
			&dwHandle);
		return;
	}

#ifdef UNICODE
	lpfnGETFILEVERSIONINFOSIZE lpfnGetFileVersionInfoSize = (lpfnGETFILEVERSIONINFOSIZE)GetProcAddress(hInst, "GetFileVersionInfoSizeW");
#else
	lpfnGETFILEVERSIONINFOSIZE lpfnGetFileVersionInfoSize = (lpfnGETFILEVERSIONINFOSIZE)GetProcAddress(hInst, "GetFileVersionInfoSizeA");
#endif //  UNICODE
	dwVer = lpfnGetFileVersionInfoSize(
		_T("C:\\Program Files\\Beyond Compare 2\\BC2.exe"), 
		&dwHandle);


#else
	dwVer = GetFileVersionInfoSize(
		_T("C:\\Program Files\\Beyond Compare 2\\BC22.exe"), 
		&dwHandle);
	DWORD dwError = GetLastError();
#endif
}

Uncomment _USE_EXPLICITTo compile using explicit link that checks for the OS version and loads appropriate versions of functions depending on UNICODE being defined or not.

JohnCz

I changed to the non ex version for now, turns out I have a lot of errors to fix in my program to run in XP nice and smooth. I haven't written all the code for the GetFileVersionInfo yet, I have to package the program first, post it on the internet, and then go back and finish the code. Give me a couple of days to experiment with your post, so I can comment on it.

But thanks for the extra help.

Another thing to check:

Is your project using targetver.h? If yes, change constants to define 0x0500 to target Windows XP.

If not, make sure you define WINVER, _WIN32_WINNT and _WIN32_WINDOWS as 0x500 in stdafx.h before any include.

Compiler will then flag all errors coming from usage of the functions that are not defined in XP.

JohnCz

Yes, the wizard included it in my stdafx.h, and rc file. So I should do a temp 0x500 to make all the XP errors surface?

I think it was just the 4 functions, when I moved the project to vista to make sure that it worked, and worked all the UAC stuff. Then I moved it back to XP just to make sure all was good, and to build my deployment project.

stdafx.h

XML

#pragma once

#include "targetver.h"

#define WIN32_LEAN_AND_MEAN             // Exclude rarely-used stuff from Windows headers
// Windows Header Files:
#include <windows.h>

// C RunTime Header Files
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>


// TODO: reference additional headers your program requires here
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")

That is not guaranteed. It may also depend on SDK version you are using for build.
Compiler will flag errors if header files contain #ifdef with specific versions of windows around some functions to exclude definition for certain versions of Windows.

So, you may have some help in finding out what is excluded for XP but you may still be left with some unknowns to resolve on your own.

JohnCz

That's good advice. Let me try it on a temp basis first, and see the results. I can learn from it at least, and implement it correctly later on down the road.

Hello Friends

I am using tabcontrol first time in MFC.So,I have some question for this.
1.)I am creating a dilog in which at a time I have to show four tabs but maximum number of tabs are more than 200. As I saw that one tabCtrl showing only five tabs.
How can i Achieve this?
2.)On one tab ,i have to show seven buttons whose color will change on tab.So,fo that Do i need to create a dilaog with seven button and then add it into tab? But how Do i this for all tabs?

Thanks In Advance.
Regards
Yogesh

200 Tabs??

You should look into this google [^]and get an insight of what Tab control is and how to create tab controls. The links give you lots of links to other websites.

It is worth looking into some of them

Every new day is another chance to change your life.

Thanks For Reply.
i read all stuff related to Tab.
I came across to a problem.I am creating a tab on which I want to insert a dialog which is having seven buttons.

But when I use
m_ctlTab.inserItem for Dilaog in OnInitDialog(), it is crashing.

Do we need to set anything else to initialize tab?

Regards
Yogesh

yogeshs wrote:
But when I use

m_ctlTab.inserItem for Dilaog in OnInitDialog(), it is crashing.

You need to use your debugger to find out exactly what is happening to cause the crash.

Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness

Are you sure is crashing or just asserting? Most likely it is the latter and it looks something like this:
ASSERT(IsWindow(hwnd));
With limited info you gave in your post, I can only guess that tab object was not created (windows is not attached to the MFC object). You have to either call Create or subclass the tab control.
I would strongly suggest two things:
Reconsider 200 tabs; it seems a little too many to handle by the user (not to mention control).
Consider using property sheet (CPropertySheet) and property pages (CPropertyPage). Property pages behave like dialogs.

JohnCz

The msdn says #pragma pack(n) will change current alignment value to n.
But if n is zero, what will do?

it resets the packing to the default size

(actually, what it does depends on the compiler. some compilers don't support pack(0) at all, and some use it as a reset)

image processing toolkits | batch image processing

modified 22-Apr-12 14:33pm.

Nope. Default size is NOT stating a #pragma pack, which defaults to DWORD, ie 4 byte alignment in structures.

#pragma pack 0 means there is no packing between data members, so they are contiguous in memory.

--edit--

Actually I am talking crap. pack (1) makes data member contiguous in memory, pack (0) resets packing. DOh!

==============================

Nothing to say.

modified 23-Apr-12 4:37am.

Erudite_Eric wrote:
pragma pack 0 means there is no packing between data members, so they are contiguous in memory.

no. that's pack(1) : align on single bytes.

pack(n) specifies the structure alignment, not the number of bytes between structs.

image processing toolkits | batch image processing

Doh! Quite correct. D'Oh! | :doh:

==============================

Nothing to say.

Here n has to be 1,2 4, 8 ....
Now if don't specify any value or if the value is 0, then the members are packed to default packing size (which is 8 for many compilers).
However few compilers will throw compilation error.

Nope. Default size is NOT stating a #pragma pack, which defaults to DWORD, ie 4 byte alignment in structures.

#pragma pack 0 means there is no packing between data members, so they are contiguous in memory.

--edit--

Actually I am talking crap. pack (1) makes data member contiguous in memory, pack (0) resets packing. DOh!

(Just checked my code. Its been a few months since I did any, I guess the old memory is fading....) Smile | :)

==============================

Nothing to say.

modified 23-Apr-12 4:38am.