|
Maximilien-
Thanks for taking the time to run that experiment. You solved the problem for me. It appears to have been an issue in the first release. I found a bug post on the Microsoft site by a guy who described leaks with "some" of the controls on a dialog. Microsoft said that they were aware of it. I guess the fix was in Service pack 1... I just installed it and it works correctly now. Thanks again.
-Dan
DanL
|
|
|
|
|
Yet another happy customer!!
glad it did fix it.
Max.
Watched code never compiles.
|
|
|
|
|
I'm looking to see what files are delivered with each Windows Operating system and/or what can be replaced if older versions exist on PCs we are delivering to.
I'm testing another developer's product including the installation CD. He is delivering several DLLs and Active X components (.OCX files). The program will be installed on Windows 98, XP (none or up to Service Pack 3) and Windows 2000. The OCX's are fine. No problems.
The problem is that of some of the files he is delivering, I do not know if they are already a part of the Windows Operating System and whether they should be replaced. My testing has revealed that at least for XP (at least for Service Packs 2 and 3), XP is protecting the files from being replaced even after a temporary file is created and a reboot is performed. Dlls won't be replaced in this situation but OCXs will. We have an older installation program called Setup Factory 6 which may not be up with all of the advances to XP.
Here are the culprits:
comdlg32.dll (does this have to be replaced if a newer version is avail in the delivery?)
msvcrt.dll
mfc42.dll
Which of these files are already expected to be there and should they be replaced if the delivery package has newer versions? I replaced an older version of comdlg32.dll on Windows 98 and it broke 98 because it has a dependency on a newer version of shell32.dll. I've since changed the option to install that file on Windows 98 to "never overwrite existing file".
I also do not know why he is delivering commdlg32.ocx.
Any help would be appreciated. TIA.
|
|
|
|
|
this always turns into a bit of a mess, safest way is to use your own local copy of the dll (without installing on the system folders), although some would disagree because it defeats the purpose of shared dlls (on a system level), but its such a pain sometimes. if you maintain your own local copy (in your own install directory) then its up to you to maintain the version that's appropriate for your software and just do regular updates after that.
|
|
|
|
|
Actually, the whole reason I am doing it this way is because during testing I discovered some of the OCX's were registered in the program's local directory. Of course, if and when you do an uninstall of the program, its best to leave those files in the program's directory and not delete them. The problem is that a user who knows he uninstalled the program may look at the program's directory and see there's nothing there but DLLs and OCX and do a delete *.* and then other programs that were using the registered locations will no longer work. Same as DLL hell.
I would prefer that the files are left in the system directory such that at least there is less risk of accidental deletion by the user.
|
|
|
|
|
why are you registering them? i don't think you're doing this right... if you use them in your local install directory, they should be uninstalled with your program.
|
|
|
|
|
What? I believe that an Active X control must be registered (DLLRegisterServer and/or RegSvr32) If not, that's new to me. The problem is that other programs may have registered their version and location of an Active X control and then this program (even if it stores it in the program's local directory) changes the location (because it registers it) so that any program using the previous version now is using the just installed control in a different location.
If I am not being clear, there are two problems. One with DLLs which I am not registering, and one with OCX's which I registering. I may be able to do as you suggest with the DLLs but not with the OCX's.
modified on Thursday, April 14, 2011 6:57 AM
|
|
|
|
|
Actually, Microsoft has declared msvcrt.dll to be a system level component and not to be used anymore by applications. So, probably somewhere starting XP (SP2?) you should at least not touch that component.
See http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx[^]. For more on known dll's, check out http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx[^] for instance.
And for the love of god, don't touch comdlg32.dll. On older systems, if you are delivering a newer version I'm guessing it's ok, but I've had multiple times that poor installers overwrote the proper version of it, making me download a proper version from the internet again.
And mfc42.dll, it seems to have a version number in the filename, so I'd say don't touch it if its there. If it's not, install it.
Then again, I'm not an expert on any of this. But please be very reluctant to overwrite dll's (and ocx's for that matter). Only if you know you have a good installer that can check and be sure that a version on the system is newer should you consider overwriting. And, you can always display a pop-up to the user asking for confirmation as some installers do.
Best Regards,
MicroVirus
|
|
|
|
|
Thanks, MicroVirus. Took all your suggestions to heart. Besides msvcrt.dll, I also decided not to deliver comdlg32.dll.
|
|
|
|
|
I want to do an user interface in c++, I will use glui library.
I added the library as the net says.
But I could not the compile any code.
I always take the same errors:
Error 16 error LNK2019: unresolved external symbol "void __cdecl myGlutIdle(void)" (?myGlutIdle@@YAXXZ) referenced in function _main
Error 33 error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::locale::facet::_Register(void)" (__imp_?_Register@facet@locale@std@@QAEXXZ) glui32.lib
and so on....
How can I fixed it? I searched everywhere 
|
|
|
|
|
If you are getting to the link stage of compilation then its probably that you are not linking in the required library but you have sufficient include files so there are no compile errors.
It's been a while since I have work with Glut but I think there is a Glut.lib that you should add to the linker section of the project settings.
|
|
|
|
|
Help! After windows update with KB2465361 I get crashes everywhere. My application is based on Ultimate Toolbox. MS created an own CMFCToolbar. In Ultimate Toolbox this has been renamed to COXToolbar, but it crashes somewhere in there. I've replaced the toolbar with the MS CMFCToolbar, but now my app crashes while opening a file inside filecore.cpp. Anyone else out there suffering similar problems and a way out of this?
Regards,
Franz
|
|
|
|
|
If you don't want to debug into COXToolbar, probably the best thing is to create a new app, then move your old code into the new app structure, just to make sure everything is hooked up correctly.
|
|
|
|
|
Debugging should not be the problem  , but probably I do not understand what's going on  .
The problem is here:
afxbasepane.cpp line 133 does a call to SetPaneStyle(dwStyle | GetPaneStyle());
This runs into virtual COleDropSource* GetDropSource(), which I do not understand. It seems that there is some linking problem, since GetPaneStyle does not exist inside OXCoolToolBar. This is strange.
|
|
|
|
|
...found out. During the update of the ultimate toolbox to Version 9.3 (Update 05) I missed one line in OXCoolToolBar.h in 1722. Instead of #define CToolBar COXMFCToolBar there was a #define CToolBar CMFCToolBar, which lead to the confusion. As I was close to getting nuts and calling for the priest I recognized this new line in the new code base of 9.3.
|
|
|
|
|
Hello, I need to rotate 90° my "graphical objects" on screen (text, lines, rect....)
Is it possible to do it just by changing any VIEW properties or anything similar ?
thanks
|
|
|
|
|
|
Thanks for your suggestion, I'll try.
Don't you know if there is any MFC similar function ?
|
|
|
|
|
|
Many thanks again
It was simple !!!
But I just have VisualStudio 2003.
I think I need an upgrade !
thanks Chris
|
|
|
|
|
|
Hi all,
i want to identify when user type other than The 7 bit default alphabet character in EditBox.
or
find after end of typing the editbox value contains other than 7 bit default alphabet character or not.
please tell me how can i find this.
thanks in advance.
|
|
|
|
|
Two things:
1. Is that even possible? Most windows (including most type of edit boxes or other input controls) don't even accept nonprintable characters, and printable ones should always be 7 bit, unless you're using some exotic alphabet like chinese - in which case you most likely have wide characters (2 byte) anyway.
(Honest question - I do not know the answer)
2. Check the characters for high order bit like this:
bool is7bit(const std::string& input) {
bool result(true);
for (std::string::const_iterator it = input.begin(); it != input.end() && result; ++it)
if (0x80 & *it)
result = false;
return result;
}
Note: obviously won't work if translated for multibyte characters since then std::string will contain wide chars as well!
|
|
|
|
|
You are really an ignorant one - isn't it ???
Ever heard of languages like france, spanish, german ???
They all have umlauts (german are ÄäÖöÜüß) and all of them have Bit8 set ...
Grrrr..
|
|
|
|
|
I'm sorry, I didn't recall what localized characters are mapped to.  Probably because I never care about ASCII encoding when I write a letter in german.  And when I care about encoding, it's somehow always english text - if it is language related at all...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
