|
|
Obviously.
However, the .net framework (20MB) is certainly not small. I don't want to distribute this dll when mfc42.dll would be fine.
Rick Eastes.
------------
|
|
|
|
|
You should just be able to distribute the MFC7 dlls. The .NET framework is only required for managed applications.
Michael 
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
From VS.Net redist.txt file :
The following merge modules have been provided for use when
redistributing the Visual C++ runtime files. Redistributing
the merge modules is the recommended method for the
redistribution of these files.
VC_atl70.msm
atl70.dll (UNICODE)
atl70.dll (ANSI)
VC_CRT.msm
msvcr70.dll
VC_CRT_IO.msm
msvci70.dll
VC_MFC.msm
mfc70.dll
mfc70u.dll
GDIPlus.msm
gdiplus.dll
MFC_Loc_E.msm
mfc70deu.dll
mfc70esp.dll
mfc70fra.dll
mfc70ita.dll
MFC_Loc_FE.msm
mfc70chs.dll
mfc70cht.dll
mfc70jpn.dll
mfc70kor.dll
VC_STL.msm
mscvp70.dll
What they are saying is that redistribuing DLLs is wrong and obstrusive to the new XP install procedure.
You must distribute what they call Merge modules (.msm files).
Btw, .mcm is a subformat of the general Windows Installer SDK (.msi database).
Otherwise it won't install on XP, depending on the profile.
Have fun.
And if you still want to distribute sharewares on a low deployment basis (for 9x for instance), just distribute these :
mfc70.dll
msvcr70.dll
msvcp70.dll (stl)
msvci70.dll
I recommend to put these files in the app directory, not on system32.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
I recommend to put these files in the app directory, not on system32.
If you do this, it's better statically linking to MFC. This way, the installer size will be smaller, since only the needed code will go to the final .EXE
Concussus surgo.
When struck I rise.
|
|
|
|
|
Well Daniel I believe you're right, at least in theory,
But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation).
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation).
I've never had a problem with statically linking. Perhaps you wrote some bad code?
StephaneRodriguez wrote:
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
Yikes! I still suspect that isn't true, but I greped the mfc dlls and mfc42.dll has DllRegisterServer in it. Thankfully none of the MFC70.dll's have that in there so maybe they've changed things.
Joel Lucsy (jjlucsy@ameritech.net)
|
|
|
|
|
StephaneRodriguez wrote:
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
This isn't true:
1. MFC dlls are not COM components. You can't regsvr32 mfc70.dll. (But you can create COM components with MFC).
2. COM components doesn't register themselves each time they are loaded.
3. With a COM DLL, it doesn't help installing the DLL on your app directory, because, when registered, it will be the only one DLL to be instantiated.
Concussus surgo.
When struck I rise.
|
|
|
|
|
Daniel Turini wrote:
MFC dlls are not COM components
Fair enough for mfc7, I admit I didn't chcked the exports functions before posting an answer,
And I swallow a small raisin.
|
|
|
|
|
My MFC application compiles successfully in both VC++7.0 and VC++6.0 but I feel I have wasted my time and money buying VC++7.0
WHY? I need to have a small distributable.
Here are two senarios:
1. Compile with .NET
Need MFC70.dll which most computers don't have.
2. Compile with VC6
Runs on ALL computers without ANY additional dll's
 Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL
Rick Eastes.
------------
http://www.eastes.net
|
|
|
|
|
Yes, somewhat waste of money especially if you don't have C# in the package you bought.
What's more is that MFC70 has STL embedded everywhere, much harder to debug a callstack than the previous release IMHO.
For some programmers however, MFC70 is a new step to achieve robustness and so on,
And I swallow a small raisin.
|
|
|
|
|
RickEastes wrote:
Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL
Have you tried changing the LIB and INCLUDE search paths ?
This probably would help...
Concussus surgo.
When struck I rise.
|
|
|
|
|
How do I prevent a window from animating? I have tried AnimateWindow(hwnd, 0, 0) ,but it is not working.
|
|
|
|
|
Er, what sort of animation are you talking about? Surely it's not just sitting there by itself, animating? Do you mean that little thing with the semitransparent rectangles when it gets minimized? 
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
Actually I am doing a Win32 sample and when I work with Ownerdrawn menus, The menu animation is interrupting with ownerdraw in the first painting. So I want to turn off animation. I have the HWND of menu.
Thanks,
Derick
|
|
|
|
|
Check out SystemParametersInfo() with the SPI_SETMENUANIMATION flag. May be a bit overkill, but could work.
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
Hi,
I have finished a project with windowns 2000 profesional and VC++ 6.0. Now i want to run the exe file with different window OS. I really want to know how to make the the exe file run correctly with any windows OS, such as, windows95, windows98, windows ME, windows XP and so on?
Thanks in advance!
chen
|
|
|
|
|
If you don't have a PSDK installed, then it will work fine. If you do, then you may find you've used API's not supported on older versions of Windows. If that is so, all you can do is change your code or late bind to those functions and hope none of them are essential ( i.e. then it will work on the older OS', but only if you detect the OS and make sure that code is never run. )
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Hi I am setting my dialog based app's position in OnInitDialog() using
SetWindowPos(NULL,0,0,100,100,SWP_NOZORDER);
Unfortuanately this does not work as it places it in the middle of the screen. If I add 1 to either of the X or Y positions it places it correctly (but out by 1 obviously)
If I use the above code elsewhere in the program its position is correct.
This occurs only in OnInitDialog() so that must be the problem, Any suggestions?
---
|
|
|
|
|
MFC does some additional work during its WM_INITDIALOG handler, after your OnInitDialog() returns. It compares the size/position of the dialog before and after calling OnInitDialog(). If both are exactly the same, it concludes that you have no special sizing/positioning code and calls CenterWindow() for you.
--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I don't know why I can't figure this out, but can someone please help me change the icon associated with my .exe file?
Not jsut changing the one in the resources because that just changes it on the taskbar, not the .exe.
Any suggestions?
Thank you.
|
|
|
|
|
Sorry, it *is* the one in resources. Make sure
- it's the first icon in the .exe (you may need to view the .rc file as text to verify this)
- you're editing both the 16x16 icon *and* the 32x32 icon (they're stored together, Windows loads the correct one) and
- you may need to restart Explorer if it's being obstinant about caching the old icon.
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
Like Shog said it is the resource one. From what you are describing you have other icons in the project resources. Just ad another copy of your app icon and name it something like 1 so it appears at the top of the list.
- Matt Newman / Windows XP Activist
-Sonork ID: 100.11179
"You can't seriously believe that you could get away with suing someone over quoting text from a message posted in a public forum, can you?" - John Simmons
|
|
|
|
|
When I mix 2 pin-enumerations, a fatal error appears saying that 5 objects are left referenced.
But all interfaces are released properly.
Somebody who knows what's going on here?
HRESULT hr=S_OK;
.
IEnumPins* pEnumFirst=NULL;
hr=(*ppFirst)->EnumPins(&pEnumFirst);
if(FAILED(hr))
return hr;
.
IEnumPins* pEnumSecond=NULL;
hr=(*ppSecond)->EnumPins(&pEnumSecond);
if(FAILED(hr))
return hr;
.
IPin* pPinFirst=NULL;
IPin* pPinSecond=NULL;
.
while(pEnumFirst->Next(1,&pPinFirst,NULL)==S_OK && pEnumSecond->Next(1,&pPinSecond,NULL)==S_OK)
{
pPinFirst->Release();
pPinSecond->Release();
}
.
pEnumFirst->Release();
pPinFirst=NULL;
pEnumFirst=NULL;
.
pEnumSecond->Release();
pPinSecond=NULL;
pEnumSecond=NULL;
...and the pins have to do nothing yet! Afterwards, I want to connect them manualy.
[VISUAL STUDIO 6.0] [MFC] [WIN98/2]
 Bluute tette!
|
|
|
|
|
never mind...
should be:
while(pEnumFirst->next ...
{
while(pEnumSecond->next ...
{
...
}
}
[VISUAL STUDIO 6.0] [MFC] [WIN98/2]
Bluute tette!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
