|
I will be packaging my MFC app with Wise.Theres a third party control that requires that olepro32 and oleaut32 be registered and installed on the users machine. I guess my question is, that if I ship the version they suggest, they are older than whats already on my win2k. If the user has newer dlls too, then these older ones I distribute wont overwrite them right? (In which case, the app should still work, I hope.).
If my shipped dlls are newer than the users dlls, then it wont mess up their machine to install mine - is that right?
Thanks,
ns
|
|
|
|
|
ns wrote:
If the user has newer dlls too, then these older ones I distribute wont overwrite them right?
Well, it depends on the installer. I don't know Wise, but I'm pretty sure you can control the way files are copied - there should be an option 'leave existing file if its version is more recent'. At least there's something like this in InstallShield.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
<old installshield="">
It is true you have the overwrite-only-if-newer flag in old InstallShield.
If you put these DLLs in your app directory, then you don't even need to worry this.
InstallShield is legacy.
You must use Merge modules (.msm) files, fill a .msi database and use the Windows Installer SDK.
System merge modules such like the ones you mention are provided by MS. VS.Net provides a lot of them in the cd.
Packages are represented by GUIDs and that's by design the installer now knows if a subpackage is already installed, needs upgrade, or has been uninstalled.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
If you put these DLLs in your app directory, then you don't even need to worry this
I highly doubt if you can put olepro32 and oleaut32 in app directory - these are core OLE libraries.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Agreed, but usually DLLs loaded automatically follow the documented scheme :
- either in current path
- or in PATH environment variable
- or system dir
So I guess this works. Requires a try though...
And I swallow a small raisin.
|
|
|
|
|
Yeah, and when you mix 'system '.dlls from app directory with real system .dlls then you'll get mysterious problems. 
Not worth the effort, IMHO.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
I don't like very much the idea of the so-called "mysterious problems". Every developer should be able to know exactly what DLLs are loaded, when, and why. If they don't, how can they debug ?
Along with static DLL dependancy walker tool, I highly recommend developers to read Matt Pietrek's articles on the net, and also download tools that for instance dynamically show loaded DLLs (introductory article here).
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
Along with static DLL dependancy walker tool,
Unfortunately, this doesn't solve all problems. Your app will load .dll from app directory, however, other parts of the system located in system32 will load *their* version. If there's some data exchange going on, and it uses internal structures which evolved in time, you're in trouble.
I remember that old issue of WDJ had very nice article on that, don't have a copy at hand however.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
you need to add the case where the DLL is an ActiveX server and needs to be registered. if you add and register a new version, everything that uses that component will be using your version.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
To obscure even more, add Independant version ProgIds...
And I swallow a small raisin.
|
|
|
|
|
Tomasz Sowinski wrote:
I don't know Wise, but I'm pretty sure you can control the way files are copied - there should be an option 'leave existing file if its version is more recent'.
There is something like this on Wise also. Anyway the best and only thing to do is to test it :
- install a new W2000 on a test machine
- note the version of your system DLLs
- install your product & reboot
- look if they have changed
|
|
|
|
|
Disagreed. What about MS Windows MUI (Multilingual user inteface) available with W2K and XP ? (::LoadLibrary hooked by the OS).
And I swallow a small raisin.
|
|
|
|
|
I want to make some plugin for Ms Office,Excel. This plugin will be used to sign document, but I don't have any idea how to start (I'm not sure if it's possible to make it in c++, maybe I have to use Visual Basic). Does anyone have some idea? I will appreciate any help.
|
|
|
|
|
|
Is there any direct and efficient way to convert a number into std::string. Infact in order to convert a number to char * we can use sprintf or itoa etc. But i want to convert a number to std::string directly. If there any such way exists then please tell me.
|
|
|
|
|
You can use strstream.
Sonork 100.15206;PavelK
|
|
|
|
|
Pavel Klocek wrote:
You can use strstream.
... but you shouldn't, because it's deprecated.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
You can always use std::ostringstream:
using namespace std;
ostringstream os;
int x = 2002;
os << x;
string s;
s = os.str();
But I think for single int you should just use local char[] array and itoa, then assign to std::string.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
I just use something like this
std::string itostring(int val)
{
char buf[32] = {0};
sprintf(buf, "%d", val);
return buf;
}
int x = 4;
itostring(x).c_str();
Todd Smith
|
|
|
|
|
Give me a couple of reasons, why migrate from Visual C++ 6.0 to .net
|
|
|
|
|
Improved STL is the only reason I can see, apart from the MFC7 improvements. The VS.NET IDE isn't designed for C++ programmers (IMO).
If you don't need the new STL/ATL stuff then I'd recommend waiting for the next release.
Michael 
Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again.
|
|
|
|
|
None for me.
Needs hardware upgrade : 2.5GB free disp space, 256MB minimum, IIS+SQLServer(MSDE) required if you intend to do server-side, and a lot of horse power...
Total distaste about ATL (default "Attribute" wizards completely suck),
MSDN doc : worse than ever, totally unreadable, and as always 300000 hits for any keyword search
C#, etc. : if you develop apps for users who can afford 21MB+6MB of raw download before they can do anything, why not ?
C# UI : a total shame. There is no document/view framework, Toolbars layout suck (lame). Owner draw is virtually impossible : you need to do full WIN32 API low-level calls for simple things such like FindWindow.
MS boasts with the new "transparent" feature in all controls, but that's only when you are running W2K+, something kept silent.
New file formats everywhere. You completely drown and need at least 6 months of self-train before you start to master it.
"Attribute" programming sucks. In short, you add MS proprietary tags in your code, and this code binds compile-time, link-time, register-time and deploy-time. But there is so much freedom, and so less logic in the rules, that you end up with a total mess and don't know what you are really doing. Besides that, "Attributes" is the next level after macros, those things that make your code not debuggable.
I could add critics for year. I am just doing .Net since one month and a half, and I hate it since first day. I am just using it for self-training to make sure to be able to adapt to employers need in the future.
And I swallow a small raisin.
|
|
|
|
|
You wrote:
"New file formats everywhere. You completely drown and need at least 6 months of self-train before you start to master it"
It took me 3 days (less than 8 hours per day) to install, launch .NET for the first time, and adapt C++ app (6 Mb of sources, 1 exe, 7 dlls) and to get familiar with all new files (at least new in C++ development).
I think that 6 months is ... little overestimated.
|
|
|
|
|
You want to use the .NET Framework.
You have 2.5 Gig free on your hard drive.
You want to go through the agonising heartache of finding code on codeproject which will save you days of programming only to find it won't compile in VC.NET w/out a lot of work.
I installed my copy, after a while getting used to the new user interface I tried to port my code over, 1 week later i was back to VC6.
My advice.. unless you want to get into .NET don't bother.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Just migrated and I am not particularly impressed with it... especially with all the blurb that is says on the tin. It's not that quicker for development of C++ apps.
The IDE is more fiddly. E.g. adding a member function means you have about 7 editboxes to fill in with all sorts of reminders and hints as if we are all retards and need leading by the hand. It's just more fiddly. The IDE is also slower. Online documentation seem to pop up .NET stuff all over the place too and because the documentation is integrated in the IDE it's often harder to just flick between the code you are writing and the info you need.
The compiler is more ANSI C++ compliant so some of your old projects might not compile (esp. casting)... I don't want my code to be ANSI compliant - just want it to work.
Some improvements in MFC7.
From what I've spotted, that's about it really. Personally I would stick with V.6 for now and spend your money on beer instead. 
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
