Re: library project

Joseph M. Newcomer wrote:
The hazards of localization are that you have to create additional mechanisms to achieve
it, such as the file of text. This adds additional complexity to the creation,
management, and distribution of the product. We did a localized product in MS-DOS that
used a separate file. Not an experience I would want to repeat in Windows.

Note that for ActiveX, if you believe "the interface changes", then you are totally
clueless about writing ActiveX controls. One of the key rules of ActiveX is that the
interface, once published, NEVER changes, and to violate this rule is a deep failure on
the part of the programmer. Therefore, the interface cannot change.

Nice try to put down another poster with different opinions to your own, but you'll have to do more than quote out of context to make any headway here.

You might live in a world where the specifications never change and you implement a perfect solution on day 1. But I don't. Extra methods, changed parameters, someone "improoving" a dll; these are my daily bread and butter. In an ideal world once a (COM) interface is registered it shouldn't change. But it can, and does. Madness, you might say, but it's still a fact. And when you dynamically link it's out of your hands. *You* might not be one who changed it, but your exe has to live with the consequences. Static linkage gives you the peice of mind of knowing that "when it's in, it's in."

I'm not saying always staticly link, but I wouldn't rule out static linkage just because you have to build dialogs dynamically. Once you've done a couple it's really quite trivial.



joe
On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@xxxxxxxxxxxx> wrote:


Hi,

Just my 2p worth. Dynamically building dialogs isn't really so tricky. I don't know what problems Joe was alluding to. Dialogs build from resources are anyway build at runtime in a similar way. Look at http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.

As far as localisation, you could always access a text file of string translations for the labels, and defautl to a language if no suitable file is found. Quick and dirty at least. The problem with dlls and ActiveX is when your interface changes your exes don't work until you relink. With a static library if it's in it's in.

Bill < wrote:

Hi,

I'm trying to create a library of one piece of code so the source can be kept secret and only the header and the library file need to be included in projects that use it. This is for use within my company.

The library needs one dialog box to enter some data. I created the library and put the dialog inside. I use this library in a project but the dialog cannot be created. I get an error -1 from DoModal(). I remember seeing once that a project can only have one resource file, so maybe my library dialog is not getting included in the final executable. Am I right? Is there a way to get it in there?

I thought I could maybe make this a DLL, but 1. I've never done one before and 2. I want to final executable to stand alone without a DLL I must also supply.

I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an uphill battle. I finally got a dialog box to display but the first button i tried to add doesn't display. Then i'm wondering how do I link the button (or other controls) to the function or variable that I would normally use Class Wizard to associate. Does anyone have any exmaple program for this?

Thanks,

Bill



Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.