library project

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


0
Bill
12/17/2008 9:47:13 AM
vc.mfc 33608 articles. 0 followers. Follow

24 Replies
1961 Views

Similar Articles

[PageSpeed] 40

"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

0
12/17/2008 9:53:25 AM
>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
0
davidl7375 (2060)
12/17/2008 9:54:03 AM
"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


0
Bill
12/17/2008 1:27:37 PM
>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
0
davidl7375 (2060)
12/17/2008 2:14:09 PM
"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


0
Bill
12/17/2008 3:41:51 PM
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
0
newcomer (15974)
12/17/2008 4:51:14 PM
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
0
newcomer (15974)
12/17/2008 4:52:27 PM
>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
0
davidl7375 (2060)
12/17/2008 5:02:05 PM
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.
0
nothanks5518 (121)
12/17/2008 5:34:12 PM
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
0
newcomer (15974)
12/17/2008 9:38:34 PM
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!
0
nothanks5518 (121)
12/17/2008 9:58:09 PM
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
0
newcomer (15974)
12/18/2008 1:13:48 AM
"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

0
dc2983 (3206)
12/18/2008 2:01:18 AM
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
0
newcomer (15974)
12/18/2008 4:48:58 AM
"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 

0
dc2983 (3206)
12/18/2008 5:06:05 AM
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
> 
> 
0
cpeters (15)
12/18/2008 10:04:03 PM
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
>> 
0
jwood (1292)
12/18/2008 10:47:44 PM
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
0
newcomer (15974)
12/19/2008 6:43:26 PM
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
>>> 


0
Bill
12/20/2008 2:42:37 AM
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
0
cpeters (15)
12/20/2008 6:09:14 PM
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
0
newcomer (15974)
12/22/2008 3:50:38 AM
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
0
cpeters (15)
12/23/2008 5:20:24 PM
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
0
newcomer (15974)
12/23/2008 6:44:13 PM
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 


0
Bill
12/24/2008 2:14:56 AM
Reply:

Similar Artilces:

Are these libraries standard libraries
Hi, I have not been able to figure out whether portlib.lib and console.lib are standard libraries (i.e. operating system libraries or language run time libraries etc as opposed to libraries written by an application programmer)or not. I will be grateful if somebody could tell me. Actually, while linking code against other three third party libraries I got "could not open library" for these two libraries. I suspect the third party libraries referenced these two libraries but I am unable to figure out whether these libraries are system libraries are not. regards, nure They look like...

checking out files from library
New to Sharepoint. When we check out a doc, it checks out, but nothing else happens--doc doesn't open, no dialog box appears, it's not saved anywhere. It will only open (and offer a dialog box regarding check-out) when you click the Edit Word doc option. Any idea on how to resolve? BTW, we use Word 2003, which doesn't allow dicating where offline files are checked out. Thx-- Jack, When you tell SharePoint to "check out" that's what it does. It doesn't know, unless you tell it, that you want to edit it. Instead, only use the "Edit wit...

Any way, with 2003, to download larger clipart library rather than a few at a time?
With Office 97, I was able to download a very large clipart folder (900+mb) when installing the program, and it was very nice not having to insert the disc or deal with the internet. Is it possible to do this with Office 2003? I suppose they don't have that type of data base on the disks (I couldn't find it anyway), since they are relying more on the web interface, but I can't find out where, on the web site, to download a large "general" library. What is the point of having an 80 GB disk if you can't use it! :0) There is a limit, 120 images or 3.5 MGB each vis...

EPM Project Plan Template Publish Issue
I'm trying to save and publish a template and the publish is grayed out. Also we are noticing that the template that we originally published is hanging when someone tries to open/new from computer the template. Please advise. Thanks MK You need to have administrator role enable for your project server account when saving the template. -- Michael Wharton, MBA, PMP, MCSD, MCSE+I, MCDBA Wharton Computer Consulting, Inc "Managing Efficiency thru Technology" "MK" wrote: > I'm trying to save and publish a template and the publish is gray...

How can I add a CDaoRecordview and/or CDaoRecordset class to a project in VC2003?
Hello group I have a problem. I don't know how add CDaoRecordset or/and CDaoRecordview class to a project in VC2003. In VC 6 I know,but with VC2003 I do: 1. Click Project. 2. Add Class 3. Click Category/MFC -> MFC class 4. I don't see the CDaoRecordset or/and CDaoRecordview class in base class list. Please anybody, help me!!! Thank's in advance ...

Microsoft Visual C++ Runtime Library error when starting Outlook XP
I just upgraded my Dell PII 400 from W2000 SP4 to WXP SP1. I was having a lot of problems with Outlook XP (all updates applied) crashing multiple times while in use, which was 1 reason for the upgrade. Now when I start Outlook, 9 out of 10 times I get a message box entitled: 'Microsoft Visual C++ Runtime Library' with the text: 'Runtime Error! Program: C:\PROGRA~1\MICROS~2\Office10\OUTLOOK.EXE abnormal program termination.' When I click OK, Outlook closes. The next time, it starts OK, but has to scan the Personal folder for errors. Fixes? Britt Dickson ...

Tips and tricks on moving to Microsoft Project Server
Hi Everyone, My company has finally given into my pleas and we are going to get Project Server. I'm curious for those who have graduated to this what their thoughts on it are from implementation to merging existing project plans to standard field layouts. Any thoughts would be appreciated. -- texmaster ------------------------------------------------------------------------ texmaster's Profile: http://forums.techarena.in/members/142408.htm View this thread: http://forums.techarena.in/microsoft-project/1306990.htm http://forums.techarena.in ...

Project Accounting Web based Time and Expense Entry
Is anyone aware of a Time and Expense Entry product that has the following features? 1. Links to Great Plains project accounting (or at least could accomodate it fairly easily). 2. Is web based. 3. Allows for time and expense approval at the project level rather by employee manager/supervisor. 4. Handles company credit card paid expenses (probably more a Great Plains issue). Also, any feedback on the Business Portal time and expense product would be appreciated (I haven't been that impressed with PSTE so I'm hoping that Business Portal is better). Thanks! Vicky Olympic...

inputing items from a database list to a project list
Is it possible to have on database list one a page and a project list on another and add items to the project list by double clicking an item in the database list??? This example assumes your database is in column A on sheet1 and your list is on sheet 2. Double clicking in the database copies the target value to the bottom of the list on sheet2. Lance Example: Private Sub Worksheet_BeforeDoubleClick(ByVal Target As Excel.Range, Cancel As Boolean) Application.EnableEvents = False If Target.Parent.Name = "Sheet1" And Target.Column = 1 Then With Worksheets("sheet2") ...

How Project Calculates Slipped, Slipping, and In Progress
Can someone please explain how Microsoft Project classifies tasks into the following categories for filtering purposes: Slipped Tasks, Slipping Tasks, In Progress Tasks. I am using Microsoft Project 2007. Thanks! Connie Connie, Easiest thing to do is look at how Project defines them in the filter. Menu: Project/Filtered For/More Filters/ .... select the filter of interest, then press the Edit button. You can there how they are defined. --rms www.rmschneider.com Connie wrote: > Can someone please explain how Microsoft Project classifies tasks into >...

Compare differences in configurations in MS Project Server?
Good morning, We're switching over from a single developer model to a multi developer model for MS Project Server 2007. One concern is being able to compare the differences in configurations between development/test/production systems. For example, I've created a new Enterprise Custom Field on my development system and didn't make a note of it to recreate it in a test system. Is there a way to compare the systems to see any differences? I would assume we could compare the sql tables. Does anyone have any recommendations? Thanks, Jonathan -- jkullgren -...

MS Project 2003 Clarity Integration Field Mapping
I am using MS project 2003 with full Clarity integration and noticed that there is a neat field available when you use the Workbench scheduling tool - Pending Time Entry. Does anyone know how I can get the field/column mappings between MS Project 2003 and Workbench when integrating with Clarity? ex. in Workbench ETC is the same field as Remaining Work in MS Project 2003. What about all the others??? ...

Cannot keep resources out for editing
We are using Project Server 2003 Cannot keep resources out for editing. Although you have permissions to add resources, you do not have permissions to keep all of them checked out for editing. Contact your server administrator to get permissions to Edit Resource Data, so that you can check out the resources that you just added." The person adding these resources is an administrator on Project Server. Groups, Categories and Security templates are defaulted to the administrator settings. The resources are added as users to projects server, but not to the global resou...

RMS Consultant needed
Looking for a consultant to write some code that will allow us to run a Stored Procedure or SQL code from a custom button. The SP or SQL code is basically creating a new kit itemlookupcode from a parm that is passed to the SP or SQL code. I had this working as a trigger since it was policy to create a kit for each new item being created that belonged to a particular department and category. Now policy has change and the kits are created as required. I have the sql code so it should be too big a project to do. Email me if you are interested in doing this project. I will provid...

business portal project accounting #2
When will project accounting functionality be in business portal. We have a high need for business entities based on project data as well as making requisition management integrate with project po's. PA Time & Expense was a good start, although that product lacks alot of functionality, now what about all the other peices to manage projects in Business Portal??? ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do n...

SDK Database Diagrams for Project Accounting
The Database Diagrams for the SDK are available for only Core Microsoft Dynamics GP modules. We would like to see Database Diagrams for Project Accounting created. ---------------- This post is a suggestion for Microsoft, and Microsoft responds to the suggestions with the most votes. To vote for this suggestion, click the "I Agree" button in the message pane. If you do not see the button, follow this link to open the suggestion in the Microsoft Web-based Newsreader and then click "I Agree" in the message pane. http://www.microsoft.com/Businesssolutions/Community/Ne...

MFC Appwizard-created project compiles in debug but not in release (2nd try)
Hello and thank you for trying to help. I have an MFC project that compiles just fine in debug config but not in release. It produces the error commonfunctions.cpp(901) : error C2065: 'GetDeviceMediaWidths' : undeclared identifier commonfunctions.cpp(902) : error C2065: 'GetDeviceMediaHeights' : undeclared identifier commonfunctions.cpp(1089) : error C2373: 'GetDeviceMediaWidths' : redefinition; different type modifiers commonfunctions.cpp(1097) : error C2373: 'GetDeviceMediaHeights' : redefinition; different type modifiers commonfunctions.h is included at t...

EndNote X2 Specified Word Library cannot be Unloaded because its i
My network guy just gave me a new PC with Office 2007. Office is networked and I am now getting this message when I start Word: EndNote X2 "Specified Word Library cannot be Unloaded because its in use" Suggestions? ...

Can Anyone help me with a Technology Lending Library?
I know there is one already for Access 2007 unfortunately I am using 2003. I need the very same one so that I can create a database for our teachers when checking hardware & software out. I would appreciate any help. Thanks in advance! -- Cathie Weber Technical Instructional Assistant Twin Creeks Elementary School Radaris: bellmay Zarcone. People Search & Background CheckFeb 24, 2010 ... Jeramie bellmay 2006 graduate of East Stroudsburg High School in East stroudsburg, PA is on Classmates.com. See pictures, plan your class ... radaris.com/p/bellmay/Zarcone/ &...

Writing a DLL program with MFC static library?
How can I make a DLL program which uses MFC static library? Please reply. Thanks in advance. Regards, Hyun-jik Bae Create your Project/ Application with wizard, in VS IDE and SEE/ READ/ WATCH all the options CAREFULLY. "Bae,Hyun-jik" <imays@NOSPAM.paran.com> wrote in message news:uGmgmsfUFHA.3436@TK2MSFTNGP09.phx.gbl... > How can I make a DLL program which uses MFC static library? > > Please reply. Thanks in advance. > > Regards, > Hyun-jik Bae > > ...

create a project without dialog
I did a client server program..I need not any GUI in client side.....So in MFC Appication how to create a project without dialog.....?Plz help me..... Cant u use win32 application with MFC support if you do not want any UI. "Sanju" <mnair.lekshmi@gmail.com> wrote in message news:1165922375.332718.95240@73g2000cwn.googlegroups.com... >I did a client server program..I need not any GUI in client side.....So > in MFC Appication how to create a project without dialog.....?Plz help > me..... > Sanju wrote: > I did a client server program..I need not any GUI in...

Project Button in Employee Maintenance
When I go to the employee maintenance window (Cards>>Payroll>>Employee), I do not have a "Project" button. Does anyone know how I can add this button. I am working in GP 7.5. Thanks. Ben Assuming you have Project installed, use Advanced Security or Standard Security to grant access to the alternate version of that window from the project dictionary. Advanced Security (Setup >> System >> Advanced Security) 1) Select User(s) 2) using By Toolbar (By Menu) view go to Cards >> Payroll >> Employee 3) Expand the window node and select Project f...

playing tracks from library
the sound is breaking up on my tracks about 10 seconds before the end of the track and then returns to normal. how can i stop this. If your using a Dell, disabling all enhancements might solve it http://thewelltemperedcomputer.com/SW/Trouble/Dell.htm "sean370" wrote: > the sound is breaking up on my tracks about 10 seconds before the end of the > track and then returns to normal. how can i stop this. ...

slightly complicated project
Some of you experts will probably snicker at this as being SO simple but being a newbie to Access, I'm perplexed as how to approach it. Basically, I'm trying to verify 2 inventories: one real (as in a physical inventory) and one is what is expected to be there, we'll call it "claimed". All quantities are 1 as each entry in the physical inventory has a serial number and bar code. The problem arises in that some of the claimed inventory is by model only so some are claiming 3 of model 1600 so we do not have unique records. Also, none of the claimed have barcodes listed. ...

How can i set up my project to be a brochure setup?
I am trying to make a brochure for work and all I have is Microsoft Word. How can I do this? There are many brochure templates available in the Microsoft Office Template Gallery at http://office.microsoft.com/templates/default.aspx? But if you have a pretty good idea what you want, you might be better off starting from scratch (the online templates contain a lot of text boxes and wrapped graphics that get out of whack easily when you try to modify them). Usually, "brochure" implies something folded in thirds (if Letter) or fourths (if Legal), and a multicolumn layout ...