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

"Bill >" <<don't want more spam> wrote in message 
news:uqApdwCYJHA.5108@TK2MSFTNGP04.phx.gbl...
> 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

You could try building the dialog, etc outside the library project you're 
working on, then use FindResource and LoadResource to get at the data, which 
you could then encode for inclusion in your static library.

I'd build it so the program in the end first tries to FindResource on the 
same resource though, so the end user can override the dialog.

You probably want to use DLGTEMPLATEEX, and have a peek at Raymond Chen's 
excellent blog:
https://blogs.msdn.com/oldnewthing/archive/2004/06/21/161375.aspx

Anthony Wieser
Wieser Software Ltd

>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().

Bill,

Static libraries don't contain any resources (but nothing in the IDE
or tools tells you this). You either need to create a DLL (which can
contain the dialog resource) or you'll have to include a copy of the
dialog resource along with the static library in the projects that use
it. The DLL option should be the easier and more manageable way to go.

>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.

In that case you need to supply both the static library and dialog
resource for inclusion in your projects.

Dave

"David Lowndes" <DavidL@example.invalid> wrote in message 
news:2sihk418ljnblkedmflb6vp7j6v3k5daaj@4ax.com...
> >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().
>
> Bill,
>
> Static libraries don't contain any resources (but nothing in the IDE
> or tools tells you this). You either need to create a DLL (which can
> contain the dialog resource) or you'll have to include a copy of the
> dialog resource along with the static library in the projects that use
> it. The DLL option should be the easier and more manageable way to go.
>
>>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.
>
> In that case you need to supply both the static library and dialog
> resource for inclusion in your projects.
>
> Dave

Dave,

In your method, what is the best way to include the resource? I just make 
the .rc file but it wants resource.h which has #defines that look like they 
might conflict with the project that uses the library.

Thanks,

Bill

>In your method, what is the best way to include the resource? I just make 
>the .rc file but it wants resource.h which has #defines that look like they 
>might conflict with the project that uses the library.

Bill,

Other than the dialog ID value, it shouldn't matter if the ID values
for the controls in a dialog clash with other dialog control IDs.

Dave

"David Lowndes" <DavidL@example.invalid> wrote in message 
news:q52ik4d9vtf7p8fum72f269o50362t7u8r@4ax.com...
> >In your method, what is the best way to include the resource? I just make
>>the .rc file but it wants resource.h which has #defines that look like 
>>they
>>might conflict with the project that uses the library.
>
> Bill,
>
> Other than the dialog ID value, it shouldn't matter if the ID values
> for the controls in a dialog clash with other dialog control IDs.
>
> Dave

Dave,

Sorry for being blur but so far i've just used the visual editor in a single 
resource project. So how do I do this?

Would I have to include the library's .rc into the project's .rc? Would I 
then just manually make sure the dialog ID is unique?

Or do I have to create the dialog visually in with the set of dialogs for 
the project? This would make sure the ID is unique.

And in either case, isn't the the dialog ID already compiled in the library? 
That would mean the value has to be defined already at library compile time 
and therefore could still conflict, yes? Or is the dialog ID value not 
resolved until link time in which case the is can work? (I'm at home now, 
not at work where I can experiment on this.)

Thanks for any more tips.

Bill

See below...
On Wed, 17 Dec 2008 17:47:13 +0800, "Bill" <<don't want more spam>> 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.
****
This means you should deliver a DLL, or a COM component.  You can deliver a static
library, but as you will see below, this will not work if dialogs are involved.

What needs to be "secret" if it is used within the same company?  Everyone has signed the
same employment agreement...
****
>
>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?
****
Create your library as a DLL or COM component.  You cannot solve the problem if it
involves using a resource segment and a static library.  There is no way to "put the
dialog inside" a static library, short of using dialog templates and creating it "by
hand", but that has other problems.
****
>
>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.
****
Not possible.  If you want a dialog, you have to do a DLL.

But why do you need the dialog in the library?  There's nothing "secret" about a dialog,
so why not just provide the dialog in source form with calls to the library?  Then anyone
can use it.  And it doesn't violate your idea of "secret"
****
>
>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?
****
Read the rules about dialog templates and in particular the alignment requirements.
Putting a dialog template in means you cannot localize the product because this would
require a STRINGTABLE entry, and that limits its usefulness.

You "link" the buttons in the same way you would normally: DDX_Control, ON_BN_CLICKED
handlers, etc.  You can't use a wizard to add them, but have you ever heard of a "text
editor"?  

Or, to simplify things, create the dialog in the resource editor.  Add everything in.
Done.  End of story.  Then take the dialog template that is created, and embed it in your
code.  You can even write code that does a FindResource/LoadResource/LockResource and
dumps the bits out, and you can then happily reformat them into a reasonable
representation.  You could even just do it as a DWORD array, as long as you keep a tool
around that can read a real template and dump it out as a DWORD array as you need to make
changes.  Your problem is that you need to be lazier, and not ask "how can I do this?" but
"how can I get some other tool to do this for me?"

If you download the CD for our Win32 book (www.flounder.com/downloads.htm, 13MB) and look
at the Pizza project, you will see a set of macros I wrote for constructing dialog
templates.  But I'd work on building a tool that would dump the dialog template.  Probably
would take less than an hour to write if you don't care about it looking pretty.

But remember that with this method you lose all ability to do localization, because all
the strings are hardwired.
				joe

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

Give the dialog some huge ID.  It doesn't "guarantee" it is unique, just makes it
extremely unlikely there will be a collision.
				joe
On Wed, 17 Dec 2008 23:41:51 +0800, "Bill Brehm" <don't want spam> wrote:

>
>"David Lowndes" <DavidL@example.invalid> wrote in message 
>news:q52ik4d9vtf7p8fum72f269o50362t7u8r@4ax.com...
>> >In your method, what is the best way to include the resource? I just make
>>>the .rc file but it wants resource.h which has #defines that look like 
>>>they
>>>might conflict with the project that uses the library.
>>
>> Bill,
>>
>> Other than the dialog ID value, it shouldn't matter if the ID values
>> for the controls in a dialog clash with other dialog control IDs.
>>
>> Dave
>
>Dave,
>
>Sorry for being blur but so far i've just used the visual editor in a single 
>resource project. So how do I do this?
>
>Would I have to include the library's .rc into the project's .rc? Would I 
>then just manually make sure the dialog ID is unique?
>
>Or do I have to create the dialog visually in with the set of dialogs for 
>the project? This would make sure the ID is unique.
>
>And in either case, isn't the the dialog ID already compiled in the library? 
>That would mean the value has to be defined already at library compile time 
>and therefore could still conflict, yes? Or is the dialog ID value not 
>resolved until link time in which case the is can work? (I'm at home now, 
>not at work where I can experiment on this.)
>
>Thanks for any more tips.
>
>Bill
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

>Would I have to include the library's .rc into the project's .rc? Would I 
>then just manually make sure the dialog ID is unique?

I think so - it's not something I've ever needed to do, I'd use the
DLL method.

>And in either case, isn't the the dialog ID already compiled in the library? 

Only if your library does it that way - have it passed in as a
parameter.

Dave

David Lowndes wrote:
>> Would I have to include the library's .rc into the project's .rc? Would I 
>> then just manually make sure the dialog ID is unique?
> 
> I think so - it's not something I've ever needed to do, I'd use the
> DLL method.
> 
>> And in either case, isn't the the dialog ID already compiled in the library? 
> 
> Only if your library does it that way - have it passed in as a
> parameter.
> 
> Dave

Even if a static lib solution could be concocted, it would be a Bad 
Idea.  Think of the poor soul that will eventually come behind you to 
maintain your solution.

Oh.  You want *maintainability* too?  I would have thought that the inability to do
localization would kill the idea.

It's bad enough the code has to be 'secret' within the company...
					joe

On Wed, 17 Dec 2008 11:34:12 -0600, BobF <nothanks@spamfree.world> wrote:

>David Lowndes wrote:
>>> Would I have to include the library's .rc into the project's .rc? Would I 
>>> then just manually make sure the dialog ID is unique?
>> 
>> I think so - it's not something I've ever needed to do, I'd use the
>> DLL method.
>> 
>>> And in either case, isn't the the dialog ID already compiled in the library? 
>> 
>> Only if your library does it that way - have it passed in as a
>> parameter.
>> 
>> Dave
>
>Even if a static lib solution could be concocted, it would be a Bad 
>Idea.  Think of the poor soul that will eventually come behind you to 
>maintain your solution.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer wrote:
> Oh.  You want *maintainability* too?  I would have thought that the inability to do
> localization would kill the idea.
> 
> It's bad enough the code has to be 'secret' within the company...
> 					joe
> 

I once worked for a large company that thought everything we did was 
subject to the Super Squirrel Secret Code.  Yes, it was a communication 
company - with the worst communication record in history!

There are many valid reasons to protect code, but protecting it against the person in the
next cubicle raises issues about the competence of those setting the policies.
					joe

On Wed, 17 Dec 2008 15:58:09 -0600, BobF <nothanks@spamfree.world> wrote:

>Joseph M. Newcomer wrote:
>> Oh.  You want *maintainability* too?  I would have thought that the inability to do
>> localization would kill the idea.
>> 
>> It's bad enough the code has to be 'secret' within the company...
>> 					joe
>> 
>
>I once worked for a large company that thought everything we did was 
>subject to the Super Squirrel Secret Code.  Yes, it was a communication 
>company - with the worst communication record in history!
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com...
> There are many valid reasons to protect code, but protecting it against 
> the person in the
> next cubicle raises issues about the competence of those setting the 
> policies.

Not really, it's quite common for managers to retain imbeciles on their 
staff just to avoid admitting they hired the wrong person.  Managers want to 
present a happy situation to their bosses.  And the code suffers, and the 
competent developers suffer the most.

-- David

First-rate people hire other first-rate people.  Second-rate people hire third-rate
people.

I once had the joy of working in an organization whose management aspired to fifth-rate
but didn't have much hope of getting there.  The reason I left was because of the people
they hired.

When I was starting my own business, quite often I'd come downstairs, pick up the mail,
open the bills, and realize that I owed a great deal more money than I had.  At this point
a panic reaction would set in.  "Why am I doing this on my own?  Why don't I go out and
get a full-time job?"  To deal with this, I would lay down and think about what my last
two jobs had been like, and the feeling would go away.  Then I'd start hustling, and land
a short contract that paid the bills for a few months and created some surplus.  Repeat
for about four years...but the last 18 years have been much better.  In Feb 2009 I will
celebrate 22 years of being my own business [downside: the management is still royally
screwed up, but I am no longer entitled to complain about it...]

Or, as I described it, "the reason I'm self-employed was two messy divorces and an affair
that didn't work out".  When I said this, someone who knew us said "But you and <SO name
here> are still together!" and I said "I'm not talking about my personal life, I'm talking
about my employment history".  One person understood completely because it's the reason
she's now single (but at the same job; for her it was personal life, not employment).  

The best part is I don't have to deal with people who make these policies.  
						joe

On Wed, 17 Dec 2008 18:01:18 -0800, "David Ching" <dc@remove-this.dcsoft.com> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com...
>> There are many valid reasons to protect code, but protecting it against 
>> the person in the
>> next cubicle raises issues about the competence of those setting the 
>> policies.
>
>Not really, it's quite common for managers to retain imbeciles on their 
>staff just to avoid admitting they hired the wrong person.  Managers want to 
>present a happy situation to their bosses.  And the code suffers, and the 
>competent developers suffer the most.
>
>-- David
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:lpkjk4lni2i3f0cf8oogd7mn5es9fi53q9@4ax.com...
> First-rate people hire other first-rate people.  Second-rate people hire 
> third-rate
> people.
>
> I once had the joy of working in an organization whose management aspired 
> to fifth-rate
> but didn't have much hope of getting there.  The reason I left was because 
> of the people
> they hired.
>
> When I was starting my own business, quite often I'd come downstairs, pick 
> up the mail,
> open the bills, and realize that I owed a great deal more money than I 
> had.  At this point
> a panic reaction would set in.  "Why am I doing this on my own?  Why don't 
> I go out and
> get a full-time job?"  To deal with this, I would lay down and think about 
> what my last
> two jobs had been like, and the feeling would go away.  Then I'd start 
> hustling, and land
> a short contract that paid the bills for a few months and created some 
> surplus.  Repeat
> for about four years...but the last 18 years have been much better.  In 
> Feb 2009 I will
> celebrate 22 years of being my own business [downside: the management is 
> still royally
> screwed up, but I am no longer entitled to complain about it...]
>
> Or, as I described it, "the reason I'm self-employed was two messy 
> divorces and an affair
> that didn't work out".  When I said this, someone who knew us said "But 
> you and <SO name
> here> are still together!" and I said "I'm not talking about my personal 
> life, I'm talking
> about my employment history".  One person understood completely because 
> it's the reason
> she's now single (but at the same job; for her it was personal life, not 
> employment).
>
> The best part is I don't have to deal with people who make these policies.
> joe
>

I don't know about you, but I can't be picky about whether my clients are 
fifth rate or first rate, the bottom line is I have to deal with some people 
who would ultimately benefit from locking down API's as is being suggested 
here.

-- David 

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
> 
> 

I was going to say the same thing. In fact, I may take exactly this approach 
with a current project.

It has to do with shareware registration. There's no way I want this in a 
separate DLL. Besides the fact that I prefer all my code in a single EXE 
anyay, a DLL here would just make it so much easier for hackers.

So I use a LIB file. And, for the dialog I need, I can just build it 
dynamically.

-- 
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Colin Peters" <cpeters@coldmail.com> wrote in message 
news:494ac8d6_1@news.bluewin.ch...
> 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
>> 

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.  
					joe
On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> 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@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

My thoughts exactly, Jonathon. And I was able to solve the problem.

"Jonathan Wood" <jwood@softcircuits.com> wrote in message 
news:ePQloKWYJHA.5272@TK2MSFTNGP04.phx.gbl...
>I was going to say the same thing. In fact, I may take exactly this 
>approach with a current project.
>
> It has to do with shareware registration. There's no way I want this in a 
> separate DLL. Besides the fact that I prefer all my code in a single EXE 
> anyay, a DLL here would just make it so much easier for hackers.
>
> So I use a LIB file. And, for the dialog I need, I can just build it 
> dynamically.
>
> -- 
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
> "Colin Peters" <cpeters@coldmail.com> wrote in message 
> news:494ac8d6_1@news.bluewin.ch...
>> 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 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@coldmail.com> 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@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

See below...
On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:

>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."
*****
Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
modify the interface to an ActiveX control once the design has been set.  To change the
interface, you create a NEW interface.  This is how it works.  The third-party companies
that have failed to do this have created disasters.  So if it changes, it means you have
done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
screw up because you violated design rules.

This is why COM interfaces are preferred to raw DLL interfaces if you want stability of
the interface.

So of course I'll put down someone who doesn't know what they're doing and violate
fundamental design rules of COM.  These have been established as the Right Way To Build
COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder
the caption "Interface Pointers and Interfaces")
=========
COM interfaces are immutable--You cannot define a new version of an old interface and give
it the same identifier. Adding or removing methods of an interface or changing semantics
creates a new interface, not a new version of an old interface. Therefore, a new interface
cannot conflict with an old interface. However, objects can support multiple interfaces
simultaneously and can expose interfaces that are successive revisions of an interface,
with different identifiers. Thus, each interface is a separate contract, and systemwide
objects need not be concerned about whether the version of the interface they are calling
is the one they expect. The interface ID (IID) defines the interface contract explicitly
and uniquely.
==========
So why do you say this is "my opinion" when it is stated in the Microsoft documentation as
one of the fundamental properties of a COM interface?  If you change the methods or add a
method, you have violated one of the basic design requirements, and your change is
therefore erroneous.  So you build bad code, don't be surprised if it fails.  Good code
cannot fail, because if you update the interface, you create a new interface, and new code
uses the new name; as it says above, you can support multiple interfaces.  Therefore,
there is never a situation in which you have to recompile the client code to use the COM
object.  It will always work with its registered COM object.  Or, the interface changes,
and indeed you update the code, because your code needed that new interface, but all the
old code continues to run.  Or fails because you have removed the interface, but then you
know; you don't get access faults or other problems, because either the interface is
supported, or it doesn't exist.

Sorry to disappoint you, but if you think you are allowed to change the interface specs in
COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you that you are
wrong.

So you get the interface you want and expect, if you do your job right.  If you choose to
do it wrong, you suffer the consequences.  A properly-done COM control will not have the
problems you describe.
******
>
>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.
*****
I simply don't understand the "single deck of cards was good enough for my
great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
gives you power and flexibility, and there should be no hesitation to program using modern
technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
it is fairly complex and I didn't feel like climbing the curve.  But I would have no
hesitation in using a DLL.  

Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
don't we just call all our executables a.exe and be done with it? [In case you don't know,
the cc compiler always created an exexcutable called a, unless you used the -o switch to
rename the executable file]
*****
>
>
>
>> 					joe
>> On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> 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@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joe,

Read what I wrote.

Which was:
"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." "*You* might not be one who changed it, but your exe has 
to live with the consequences."

Hopefully it's implicit that I was speaking from the point of view of 
the Active X consumer. There's nothing you can do to prevent an Active X 
supplier violating COM convention. Or in a general sense, a dll supplier 
doing the same. Both lead to the same effect; the consuming exe doesn't 
work correctly. There are almost no practical measures you can take to 
technically exclude this. You don't always work for the same company as 
the dll supplier. You don't always have jurisdiction over what gets 
"updated".

You (jumped up on your high horse and) wrote:

"So of course I'll put down someone who doesn't know what they're doing 
and violate fundamental design rules of COM."

and

"So you build bad code, don't be surprised if it fails."

Yet it's pretty common to find a consuming exe coming to grief because 
of incomaptible dlls. This is sometimes refered to as "dll hell". You 
can be the best programmer in the world and still be hit by this.

Now, one mechanism to help prevent this is static linking. There are 
drawbacks, but then everything is a balance. Ease of distribution, and 
the fact that no-one can (accidentally or otherwise) render your exe 
unrunable are advantages in my book.

You seem to have spent some time quoting COM fundamentals and slinging 
insults without actually addressing the core issue from the original 
post. Namely, can you include a dialog in a static lib (which you can, 
albeit one coded entirely in a function rather than built from a 
resource), and what are the pros and cons thereof.

It seems that you aren't very good at accepting alternative opinions. 
There's the Joe-way, and everything else must be the ramblings of an 
idiot. Maybe this is why you keep back the threat to "walk away" from 
"fifth-rate clients". Ultimately, we all have that choice, I suppose. 
But I've found I've got the most out of projects where at first glance 
things were never going to work. But then through compromise and 
innovation (and I admit, a bit of head-banging) things did actually 
work. Threatening to take the ball home is a bit childish, in my opinion.


Joseph M. Newcomer wrote:
> See below...
> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:
> 
> 
>>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."
> 
> *****
> Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
> modify the interface to an ActiveX control once the design has been set.  To change the
> interface, you create a NEW interface.  This is how it works.  The third-party companies
> that have failed to do this have created disasters.  So if it changes, it means you have
> done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
> error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
> arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
> screw up because you violated design rules.
> 
> This is why COM interfaces are preferred to raw DLL interfaces if you want stability of
> the interface.
> 
> So of course I'll put down someone who doesn't know what they're doing and violate
> fundamental design rules of COM.  These have been established as the Right Way To Build
> COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder
> the caption "Interface Pointers and Interfaces")
> =========
> COM interfaces are immutable--You cannot define a new version of an old interface and give
> it the same identifier. Adding or removing methods of an interface or changing semantics
> creates a new interface, not a new version of an old interface. Therefore, a new interface
> cannot conflict with an old interface. However, objects can support multiple interfaces
> simultaneously and can expose interfaces that are successive revisions of an interface,
> with different identifiers. Thus, each interface is a separate contract, and systemwide
> objects need not be concerned about whether the version of the interface they are calling
> is the one they expect. The interface ID (IID) defines the interface contract explicitly
> and uniquely.
> ==========
> So why do you say this is "my opinion" when it is stated in the Microsoft documentation as
> one of the fundamental properties of a COM interface?  If you change the methods or add a
> method, you have violated one of the basic design requirements, and your change is
> therefore erroneous.  So you build bad code, don't be surprised if it fails.  Good code
> cannot fail, because if you update the interface, you create a new interface, and new code
> uses the new name; as it says above, you can support multiple interfaces.  Therefore,
> there is never a situation in which you have to recompile the client code to use the COM
> object.  It will always work with its registered COM object.  Or, the interface changes,
> and indeed you update the code, because your code needed that new interface, but all the
> old code continues to run.  Or fails because you have removed the interface, but then you
> know; you don't get access faults or other problems, because either the interface is
> supported, or it doesn't exist.
> 
> Sorry to disappoint you, but if you think you are allowed to change the interface specs in
> COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you that you are
> wrong.
> 
> So you get the interface you want and expect, if you do your job right.  If you choose to
> do it wrong, you suffer the consequences.  A properly-done COM control will not have the
> problems you describe.
> ******
> 
>>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.
> 
> *****
> I simply don't understand the "single deck of cards was good enough for my
> great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
> gives you power and flexibility, and there should be no hesitation to program using modern
> technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
> it is fairly complex and I didn't feel like climbing the curve.  But I would have no
> hesitation in using a DLL.  
> 
> Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
> basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
> don't we just call all our executables a.exe and be done with it? [In case you don't know,
> the cc compiler always created an exexcutable called a, unless you used the -o switch to
> rename the executable file]
> *****
> 
>>
>>
>>>					joe
>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> 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@flounder.com
>>>Web: http://www.flounder.com
>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
> 
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

See below...
On Tue, 23 Dec 2008 18:20:24 +0100, Colin Peters <cpeters@coldmail.com> wrote:

>Joe,
>
>Read what I wrote.
>
>Which was:
>"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." "*You* might not be one who changed it, but your exe has 
>to live with the consequences."
****
Where does the Microsoft documentation say "The interface is immutable unless you feel it
shouldn't be, because you don't believe that this requirement is relevant"?  Sorry, if you
ignore the basic principles of COM design, it won't work right, and that is YOUR fault for
screwing up.  It is, by defnition, an error to change an ActiveX component interface.  If
someone does, they screwed up, and they need to be dumped on for doing something stupid.
****
>
>Hopefully it's implicit that I was speaking from the point of view of 
>the Active X consumer. There's nothing you can do to prevent an Active X 
>supplier violating COM convention. Or in a general sense, a dll supplier 
>doing the same. Both lead to the same effect; the consuming exe doesn't 
>work correctly. There are almost no practical measures you can take to 
>technically exclude this. You don't always work for the same company as 
>the dll supplier. You don't always have jurisdiction over what gets 
>"updated".
****
]Actually, there are several things you can do when an ActiveX supplier violates COM
specs, such as telling them they are stupid and irresponsible, and even finding an
alternative supplier.  Blasting them in blogs.  Ranting at their tech support.  What you
are saying is "People screw up, and therefore we cannot possibly consider building an
interface, WHERE WE ARE THE SUPPLIER, because some other supplier might screw up some
other component".  The answer is simple: behave responsibly, and your components will not
suffer from this, and therefore, you should not reject a solution because you will do it
correctly.
****
>
>You (jumped up on your high horse and) wrote:
>
>"So of course I'll put down someone who doesn't know what they're doing 
>and violate fundamental design rules of COM."
>
>and
>
>"So you build bad code, don't be surprised if it fails."
****
Yep.  Bad code fails.  And it is part of *my* responsibility to point out to people who
behave stupidly and irresponsibly that they are behaving stupid and irresponsibly.
****
>
>Yet it's pretty common to find a consuming exe coming to grief because 
>of incomaptible dlls. This is sometimes refered to as "dll hell". You 
>can be the best programmer in the world and still be hit by this.
****
Incompatible DLLs are a different question than COM interfaces, which is what I was
talking about.
****
>
>Now, one mechanism to help prevent this is static linking. There are 
>drawbacks, but then everything is a balance. Ease of distribution, and 
>the fact that no-one can (accidentally or otherwise) render your exe 
>unrunable are advantages in my book.
*****
Static linking works fine until you are given a DLL or COM component, then it no longer is
worth talking about.

Note also that you no longer have the ability to replace components, or upgrade them,
without a complete relink and redistribution of the entire file, which is a significant
disadvantage.
****
>
>You seem to have spent some time quoting COM fundamentals and slinging 
>insults without actually addressing the core issue from the original 
>post. Namely, can you include a dialog in a static lib (which you can, 
>albeit one coded entirely in a function rather than built from a 
>resource), and what are the pros and cons thereof.
*****
I already answered that in a number of ways, including pointing the OP to at code I wrote
to allow the creation of dialog templates.
*****
>
>It seems that you aren't very good at accepting alternative opinions. 
>There's the Joe-way, and everything else must be the ramblings of an 
>idiot. Maybe this is why you keep back the threat to "walk away" from 
>"fifth-rate clients". Ultimately, we all have that choice, I suppose. 
>But I've found I've got the most out of projects where at first glance 
>things were never going to work. But then through compromise and 
>innovation (and I admit, a bit of head-banging) things did actually 
>work. Threatening to take the ball home is a bit childish, in my opinion.
*****
There are downsides to several solutions.  I pointed out that creating templates mean that
there is no way to effectively localize the code without introducing additional
mechanisms.  Note that localization has other implications, such as the fact that in some
languages the labels (static controls) and input (edit controls, combo boxes) among others
have to be resized to allow for longer words.  That won't happen with hand-crafted code.  

I did not say it was the ramblings of an idiot; I said it was a poor choice for a variety
of technical and user-oriented reasons.  
*****
>
>
>Joseph M. Newcomer wrote:
>> See below...
>> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:
>> 
>> 
>>>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."
>> 
>> *****
>> Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
>> modify the interface to an ActiveX control once the design has been set.  To change the
>> interface, you create a NEW interface.  This is how it works.  The third-party companies
>> that have failed to do this have created disasters.  So if it changes, it means you have
>> done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
>> error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
>> arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
>> screw up because you violated design rules.
>> 
>> This is why COM interfaces are preferred to raw DLL interfaces if you want stability of
>> the interface.
>> 
>> So of course I'll put down someone who doesn't know what they're doing and violate
>> fundamental design rules of COM.  These have been established as the Right Way To Build
>> COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder
>> the caption "Interface Pointers and Interfaces")
>> =========
>> COM interfaces are immutable--You cannot define a new version of an old interface and give
>> it the same identifier. Adding or removing methods of an interface or changing semantics
>> creates a new interface, not a new version of an old interface. Therefore, a new interface
>> cannot conflict with an old interface. However, objects can support multiple interfaces
>> simultaneously and can expose interfaces that are successive revisions of an interface,
>> with different identifiers. Thus, each interface is a separate contract, and systemwide
>> objects need not be concerned about whether the version of the interface they are calling
>> is the one they expect. The interface ID (IID) defines the interface contract explicitly
>> and uniquely.
>> ==========
>> So why do you say this is "my opinion" when it is stated in the Microsoft documentation as
>> one of the fundamental properties of a COM interface?  If you change the methods or add a
>> method, you have violated one of the basic design requirements, and your change is
>> therefore erroneous.  So you build bad code, don't be surprised if it fails.  Good code
>> cannot fail, because if you update the interface, you create a new interface, and new code
>> uses the new name; as it says above, you can support multiple interfaces.  Therefore,
>> there is never a situation in which you have to recompile the client code to use the COM
>> object.  It will always work with its registered COM object.  Or, the interface changes,
>> and indeed you update the code, because your code needed that new interface, but all the
>> old code continues to run.  Or fails because you have removed the interface, but then you
>> know; you don't get access faults or other problems, because either the interface is
>> supported, or it doesn't exist.
>> 
>> Sorry to disappoint you, but if you think you are allowed to change the interface specs in
>> COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you that you are
>> wrong.
>> 
>> So you get the interface you want and expect, if you do your job right.  If you choose to
>> do it wrong, you suffer the consequences.  A properly-done COM control will not have the
>> problems you describe.
>> ******
>> 
>>>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.
>> 
>> *****
>> I simply don't understand the "single deck of cards was good enough for my
>> great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
>> gives you power and flexibility, and there should be no hesitation to program using modern
>> technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
>> it is fairly complex and I didn't feel like climbing the curve.  But I would have no
>> hesitation in using a DLL.  
>> 
>> Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
>> basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
>> don't we just call all our executables a.exe and be done with it? [In case you don't know,
>> the cc compiler always created an exexcutable called a, unless you used the -o switch to
>> rename the executable file]
>> *****
>> 
>>>
>>>
>>>>					joe
>>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> 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@flounder.com
>>>>Web: http://www.flounder.com
>>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>> 
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

And yet i'm happy with  my choice and I've moved on to the next challenge...

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:1qb2l4lk0feidrc8u09i97r9nad809fice@4ax.com...
> See below...
> On Tue, 23 Dec 2008 18:20:24 +0100, Colin Peters <cpeters@coldmail.com> 
> wrote:
>
>>Joe,
>>
>>Read what I wrote.
>>
>>Which was:
>>"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." "*You* might not be one who changed it, but your exe has
>>to live with the consequences."
> ****
> Where does the Microsoft documentation say "The interface is immutable 
> unless you feel it
> shouldn't be, because you don't believe that this requirement is 
> relevant"?  Sorry, if you
> ignore the basic principles of COM design, it won't work right, and that 
> is YOUR fault for
> screwing up.  It is, by defnition, an error to change an ActiveX component 
> interface.  If
> someone does, they screwed up, and they need to be dumped on for doing 
> something stupid.
> ****
>>
>>Hopefully it's implicit that I was speaking from the point of view of
>>the Active X consumer. There's nothing you can do to prevent an Active X
>>supplier violating COM convention. Or in a general sense, a dll supplier
>>doing the same. Both lead to the same effect; the consuming exe doesn't
>>work correctly. There are almost no practical measures you can take to
>>technically exclude this. You don't always work for the same company as
>>the dll supplier. You don't always have jurisdiction over what gets
>>"updated".
> ****
> ]Actually, there are several things you can do when an ActiveX supplier 
> violates COM
> specs, such as telling them they are stupid and irresponsible, and even 
> finding an
> alternative supplier.  Blasting them in blogs.  Ranting at their tech 
> support.  What you
> are saying is "People screw up, and therefore we cannot possibly consider 
> building an
> interface, WHERE WE ARE THE SUPPLIER, because some other supplier might 
> screw up some
> other component".  The answer is simple: behave responsibly, and your 
> components will not
> suffer from this, and therefore, you should not reject a solution because 
> you will do it
> correctly.
> ****
>>
>>You (jumped up on your high horse and) wrote:
>>
>>"So of course I'll put down someone who doesn't know what they're doing
>>and violate fundamental design rules of COM."
>>
>>and
>>
>>"So you build bad code, don't be surprised if it fails."
> ****
> Yep.  Bad code fails.  And it is part of *my* responsibility to point out 
> to people who
> behave stupidly and irresponsibly that they are behaving stupid and 
> irresponsibly.
> ****
>>
>>Yet it's pretty common to find a consuming exe coming to grief because
>>of incomaptible dlls. This is sometimes refered to as "dll hell". You
>>can be the best programmer in the world and still be hit by this.
> ****
> Incompatible DLLs are a different question than COM interfaces, which is 
> what I was
> talking about.
> ****
>>
>>Now, one mechanism to help prevent this is static linking. There are
>>drawbacks, but then everything is a balance. Ease of distribution, and
>>the fact that no-one can (accidentally or otherwise) render your exe
>>unrunable are advantages in my book.
> *****
> Static linking works fine until you are given a DLL or COM component, then 
> it no longer is
> worth talking about.
>
> Note also that you no longer have the ability to replace components, or 
> upgrade them,
> without a complete relink and redistribution of the entire file, which is 
> a significant
> disadvantage.
> ****
>>
>>You seem to have spent some time quoting COM fundamentals and slinging
>>insults without actually addressing the core issue from the original
>>post. Namely, can you include a dialog in a static lib (which you can,
>>albeit one coded entirely in a function rather than built from a
>>resource), and what are the pros and cons thereof.
> *****
> I already answered that in a number of ways, including pointing the OP to 
> at code I wrote
> to allow the creation of dialog templates.
> *****
>>
>>It seems that you aren't very good at accepting alternative opinions.
>>There's the Joe-way, and everything else must be the ramblings of an
>>idiot. Maybe this is why you keep back the threat to "walk away" from
>>"fifth-rate clients". Ultimately, we all have that choice, I suppose.
>>But I've found I've got the most out of projects where at first glance
>>things were never going to work. But then through compromise and
>>innovation (and I admit, a bit of head-banging) things did actually
>>work. Threatening to take the ball home is a bit childish, in my opinion.
> *****
> There are downsides to several solutions.  I pointed out that creating 
> templates mean that
> there is no way to effectively localize the code without introducing 
> additional
> mechanisms.  Note that localization has other implications, such as the 
> fact that in some
> languages the labels (static controls) and input (edit controls, combo 
> boxes) among others
> have to be resized to allow for longer words.  That won't happen with 
> hand-crafted code.
>
> I did not say it was the ramblings of an idiot; I said it was a poor 
> choice for a variety
> of technical and user-oriented reasons.
> *****
>>
>>
>>Joseph M. Newcomer wrote:
>>> See below...
>>> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> 
>>> wrote:
>>>
>>>
>>>>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."
>>>
>>> *****
>>> Note that I said this specificallyl in reference to ActiveX controls. 
>>> It is erroneous to
>>> modify the interface to an ActiveX control once the design has been set. 
>>> To change the
>>> interface, you create a NEW interface.  This is how it works.  The 
>>> third-party companies
>>> that have failed to do this have created disasters.  So if it changes, 
>>> it means you have
>>> done the wrong thing.  Once it is released, it is frozen forever, and it 
>>> is ALWAYS an
>>> error to change it, no exceptions.  This is PRECISELY so the problem you 
>>> mention cannot
>>> arise.  So don't blame me if you use the mechanisms incorrectly; it 
>>> isn't my fault if you
>>> screw up because you violated design rules.
>>>
>>> This is why COM interfaces are preferred to raw DLL interfaces if you 
>>> want stability of
>>> the interface.
>>>
>>> So of course I'll put down someone who doesn't know what they're doing 
>>> and violate
>>> fundamental design rules of COM.  These have been established as the 
>>> Right Way To Build
>>> COM Controls, and obviously you missed this critical paragraph in the 
>>> MSDN (which is upder
>>> the caption "Interface Pointers and Interfaces")
>>> =========
>>> COM interfaces are immutable--You cannot define a new version of an old 
>>> interface and give
>>> it the same identifier. Adding or removing methods of an interface or 
>>> changing semantics
>>> creates a new interface, not a new version of an old interface. 
>>> Therefore, a new interface
>>> cannot conflict with an old interface. However, objects can support 
>>> multiple interfaces
>>> simultaneously and can expose interfaces that are successive revisions 
>>> of an interface,
>>> with different identifiers. Thus, each interface is a separate contract, 
>>> and systemwide
>>> objects need not be concerned about whether the version of the interface 
>>> they are calling
>>> is the one they expect. The interface ID (IID) defines the interface 
>>> contract explicitly
>>> and uniquely.
>>> ==========
>>> So why do you say this is "my opinion" when it is stated in the 
>>> Microsoft documentation as
>>> one of the fundamental properties of a COM interface?  If you change the 
>>> methods or add a
>>> method, you have violated one of the basic design requirements, and your 
>>> change is
>>> therefore erroneous.  So you build bad code, don't be surprised if it 
>>> fails.  Good code
>>> cannot fail, because if you update the interface, you create a new 
>>> interface, and new code
>>> uses the new name; as it says above, you can support multiple 
>>> interfaces.  Therefore,
>>> there is never a situation in which you have to recompile the client 
>>> code to use the COM
>>> object.  It will always work with its registered COM object.  Or, the 
>>> interface changes,
>>> and indeed you update the code, because your code needed that new 
>>> interface, but all the
>>> old code continues to run.  Or fails because you have removed the 
>>> interface, but then you
>>> know; you don't get access faults or other problems, because either the 
>>> interface is
>>> supported, or it doesn't exist.
>>>
>>> Sorry to disappoint you, but if you think you are allowed to change the 
>>> interface specs in
>>> COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you 
>>> that you are
>>> wrong.
>>>
>>> So you get the interface you want and expect, if you do your job right. 
>>> If you choose to
>>> do it wrong, you suffer the consequences.  A properly-done COM control 
>>> will not have the
>>> problems you describe.
>>> ******
>>>
>>>>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.
>>>
>>> *****
>>> I simply don't understand the "single deck of cards was good enough for 
>>> my
>>> great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL 
>>> Is a tool that
>>> gives you power and flexibility, and there should be no hesitation to 
>>> program using modern
>>> technology.  I feel a bit out-of-place because I *don't* use COM, and 
>>> probably should; but
>>> it is fairly complex and I didn't feel like climbing the curve.  But I 
>>> would have no
>>> hesitation in using a DLL.
>>>
>>> Static linking is occasionally, rarely, useful, and I've used it once or 
>>> twice, but the
>>> basic "I want just one .exe file" attitude seems out of step with modern 
>>> practice.  Why
>>> don't we just call all our executables a.exe and be done with it? [In 
>>> case you don't know,
>>> the cc compiler always created an exexcutable called a, unless you used 
>>> the -o switch to
>>> rename the executable file]
>>> *****
>>>
>>>>
>>>>
>>>>> joe
>>>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> 
>>>>>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@flounder.com
>>>>>Web: http://www.flounder.com
>>>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer@flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm