Door/Drawer Front Designer Problems...

[DanEpps]

Here is what, I think, the problem is.

I think eCabinets is built using dynamic links to mfc80.dll to reduce the memory footprint of the program. When using dynamic linking to MFC, mfc<version>.dll must be included with the distribution. The eCabinets distribution does not include mfc<version>.dll.

From Microsoft Developer Network (MSDN) Technical Notes: Using MFC as Part of a DLL:

With regular DLLs that dynamically link to MFC, the savings in memory from using the shared version of MFC can be significant. However, you must distribute the shared DLLs, Mfc<version>.dll and Msvvcrt<version>.dll, with your DLL.

Since you (Joe) changed the binding redirect to a newer version of MFC, applications that use the older version should not be affected. If you had pointed it to an older version, it would definitely have caused problems in other applications. I am unsure whether the redirection will automatically pick up the correct version of msvvcrt, but it should.

I underlined "should" because that is the way it is supposed to work, but who knows?

[Kerry Fullington]

Joe,

Did you try using System Restore to return to a time before the eCabinets problem started?

Kerry

[Rick Deskins]

You can try to reinstall the vc++ 2005 sp1 redistributable package.

http://www.microsoft.com/downloads/deta ... laylang=en

[Joe Dusel]

Dan,

I actually changed the policy file to use the older (762) version of the mfc80.dll file. I'm assuming that this is what eCabs likes since it seems to be working fine now. The VC++ 2005 SP2 stuff that Rick suggested reloading is the 762 version. My guess is that something in the eCabs software or the peripherals is possibly indicating that a 762 or newer version of this DLL may be used. Since something that I've recently installed is using the 1833 version of DLL it installed it on my system. I think it might be related to some SQL software, and I will probably find out which one when it goes down in flames.

Kerry,

I thought about doing the system restore, but I figured that would then muck up the new programs that I installed.

Rick,

I'm not sure that reinstalling the VC++ 2005 sp1 redistributable package will help. Won't this will just put the 762 version of the DLL back to where it already is? Currently my system includes 3 versions of the mfc80.dll including 762 and the newer 1833.

Thanks for the ideas guys!!!

Joe

[DanEpps]

Dyslexia in my sorting algorithm...I saw 1xxx as being less than (thus older) 7xx.

You are correct that something you recently installed probably hosed your configuration. WinDVD is notorious for messing up MFC and forcing everything to use .1833 and I'm sure many other applications do the same. This is why MS recommends using dynamic linking with shared MFC. Every application then installs its own MFC dlls.

[Joe Dusel]

Thanks Dan.

I know that what I did is not the kosher way to fix the problem, but it's working temporarily for me until the issue gets resolved in the software. I think this is going to be an upcoming issue for others as we start to get new applications made with the newer DLLs, so it might be a good thing for the ecabs programmers to look into. If all it takes to fix it is to include a copy of the mfc80.dll file in the distribution it should be an easy fix.

Joe

[Joe Dusel]

Funny, I spoke to another user tonight and without relating my story to him he started telling me about his problem. From his description it sounded the same as mine.

Joe

[DanEpps]

I'm beginning to think the problem arises when something is installed that redirects only to the .1833 version. I have .42, .142 and .762 versions and haven't seen the problem.

Most of the problems (in general) that I read about concern version .1833 so it must be the real culprit.

[Rick Deskins]

the .1833 version of the dlls seem to cause a lot of problems for a lot of different types of mfc apps. I have found that M$ suggest installing a later pos-build version of the dlls (.3079).

http://code.msdn.microsoft.com/KB961894 ... aseId=2067