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

Similar Articles

[PageSpeed] 10

"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 (2061)
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 (2061)
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 (15979)
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 (15979)
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 (2061)
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 (15979)
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 (15979)
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 (15979)
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 (1291)
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 (15979)
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 (15979)
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 (15979)
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:

Cannot Save Project to Server
We have one schedule that we continually have trouble saving to our server. I found a similar question on this web site where the recommendation was to check for summary tasks with zero duration or predecessors or successors at the summary task level. We have eliminated all of those, but still cannot save the schedule. Does anyone have any suggestions? Hi Debbie, If you haven't already, please repost your question to the Project Server newsgroup. You're more likely to get the quick attention of a Server "guru" there. The newsgroup may be found at: ht...

strange library
Hi can anyone help, when I update my library the albums appear as seperate tracks instead of one album, makes it very dificult to find music. Dont know what to do next, has anyone come across this before. Cheers Reg Do you mean that the tracks of one album are scattered over multiple albums? To fix this, you need to give all these tracks the same value for Album Title and Album Artist. Regards -- Tim De Baets http://www.bm-productions.tk reg wrote: > Hi can anyone help, when I update my library the albums appear as seperate > tracks instead of one album, makes it ve...

Task with duration for all project
Hello, have a problem with project 2007 is the follow: Have a task of administration and control of a project, this task must to have a duration of all project. for example Development 120h 01-01-2010 to 20-01-2010 Testing 30h 25-02-2010 to 30-03-2010 Administration 30h 01-01-2010 to 30-03-2010 Is possible ? How I can do it? Tanks in advance and sorry my poor english.. Christian W This is a multi-part message in MIME format. ------=_NextPart_000_0059_01CACCF5.C6BD77C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-En...

Fixed Asset Projection Report
Hi, I am facing one problem while taking projection report. I need to take the report for a particular period. In the projection option I gave the option "Project From/To" Date ranges. But while printing the report it shows the all ranges what available in the system. (Eg:- I need report for this range ( 01/01/2005 - 01/31/2005). But while printing I am getting the details of the previous ranges also). I only need the report for the current range. I am Using Great Plains 7.5 version. How I can overcome this problem? If anybody give me the solution it would be appreciable. T...

WMP 11 not adding .avi's to the library
Hi Folks; I have Windows Media Player 11 installed with all the updates. I have the library set up to index a couple of different directories on my network. It currently indexes all .wmv and .dvr-ms files, which is great. The problem is, it's not indexing .avi files. It will play them just fine as I have the proper codec's installed but what I'm really after is a solution to it not indexing .avi files. Does anyone know why or how to get it to index them and add them to the library? Thanks! Dave Do they get added to the Other Media instead of the Video ...

Missing library???
Hi all I have a macro that starts as shown below. j$ = "THIS MACRO WILL ERASE THE SECOND & THIRD SET OF DATA" + Chr$(13) + Chr$(13) intX = MsgBox(j$, Style) When I try to run the macro I get an error message :"cant't find project or library" and the first "Chr$(13)" is hilighted.If I delete the ref to char$(13)(both of them) and rtry to run macro again , I get the same error but this time "J$" is hilighted. This macro has worked very well for a long time. It just started acting up after I reinstalled winmdows- computer crashed bad. Sure wo...

Project 2007 showing conflicting costs
Hi guys, I'm using Project 2007 and am a tad confused by the costs it calculates for my project. I've assigned the same standard prorated rate for all my resources on the Resource Sheet at 100%. When I multiply the total hours (as shown on the Resource Usage chart), by the resource rate, I get a 60% higher total project cost than that shown in the Project Statistics. The statistical cost matches the cost shown on the Task Sheet. All non-summary tasks have been assigned. MVP Mike Glen suggested I may have assigned resources to summary tasks, but on double-checking, that&...

Dynamink Link Library
When I launched Outlook 2003 I get an error window "The procedure entry point_GetIUMS@4 could not be located in the dynamic link library MSDART.DLL". I went to http://support.microsoft.com/default.aspx? scid=kb;en-us;842014&FR=1&PA=1&SD=HSCH to resolve this and I downloaded the Microsoft Data Access Components (MDAC) 2.8 but I have a problem running this .dll file. I downloaded http://www.users.on.net/johnson/resourcehacker/ know how to use resource hacker so I can view or run this file. Is there a better way of opening this file to rid my Msdart.dll error? Hi! ...

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

Project management in MS CRM 3.0
I would like to track our project through MS CRM 3.0 and track them in 4 levels. 1. level - Project - name of the project 2. level - Task - taks like .. Implementation of SW, Development 3. level - Activity - activities like ... Implementation of SW 1, implementation of SW 2, development of new module 4. level - Activity Report - report what was actual done in Activity like .... "Implementation of SW 1 - 2 hours - 1 person" All of the above would have planned start - end date (time) and actual start - end date (time). I had tried to do the folowing. I created 4 new entitie...

professional tools library should allow more than one salesperson
Sales Modifier in Professional Services Tools Library currenly only allows you to change one starting salesperson id to one new salesperson id. Well, it is possible that one terminated salesperson may have multiple invoices in which they will be divided among other salespeople. it would be very beneficial if the Sales modifier tool allowed that to happen instead of the just one and one feature ---------------- 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 th...

woodshop project
April 9, 2007: We start to talk about our next project for woodshop. April 10, 2007: We start to decide what the bridge will look like, but first Mr. Mizuta had spit us up into groups. April 12, 2007: Me and my partner Bobby K. start to talk about what the project will turn out to be when were done. April 13, 2007: We still are trying to decide what the bridge was going to look like, but then Mr. Mizuta asked us if we needed any help. April 16, 2007: Mr. Mizuta showed us what the project will turn out to be when were done with it, but we still didn't understand what to do...

How to debug calls into MFC libraries in VS2005?
I've got an MFC based application, but am having trouble tracing into the MFC libraries. The system is loading up the debug libraries from the WinSXS folder, but there isn't any symbol information for these: mfc80d.dll C:\Windows\winsxs\x86_microsoft.vc80.debugmfc_1fc8b3b9a1e18e3b_8.0.50727.762_none_29a8a38855141f6e\mfc80d.dll N/A N/A Symbols loaded (source information stripped). C:\Users\Tony\Documents\VS Debug Symbols\MFC80D.i386.pdb\A12C75C3E6A244E3B3BFBE577AB27642e\MFC80D.i386.pdb 4 8.00.50727.762 02/12/2006 09:05 68BC0000-68E0D000 [6100] hexagon32.exe: Native Any idea ...

Missing Microsoft Word 10.0 Object Library
This happens when anyone opens my file created in Excel 2000 in Excel XP instead. The file creates a word doc from excel. How can I modify my code below to make it able to differentiate between Microsoft Word 9.0 Object Library and the 10.0 Object Library Dim wrd As Word.Application BTW, it also sets Dim wrd As Objec Set wrd = CreateObject("Word.Application" The problem is not having this Missing 10.0 error back in 9.0 when the file is open in Excel 2000 again ----- Li wrote: ---- This happens when anyone opens my file created in Excel 2000 in Excel XP i...

WMP library
Hi,WMP won't play any songs,saying there is nothing in there,any help very welcome,Thanks. -- Cheers,Billy boy 212 It would be helpful if you could give us the exact error message. "There is nothing in there" is way too vague. Regards -- Tim De Baets http://www.bm-productions.tk billy boy 212 wrote: > Hi,WMP won't play any songs,saying there is nothing in there,any help very > welcome,Thanks. ...

Running total calculation projection
Hi I can't figure this one out, please help. I have built a financial data sheet that creates a projection of what the total will be which works ok, but a new entry is added each day that changes it. If the next day is blank is continues to reduce the formula out to the end of the month. I believe a vlookup formula will work but , what do I use for it not to continue to calculate until the blanks are filled? =m6/a6*A4 where m6 is totals sale A6 is the number of workdate a4 is total number of workdays in the mont Thanks Hi not really sure what you're trying to do b ut maybe the follow...

Project and Canadian Payroll Table References to SQL
I have and Excel mapping of GP tables to the SQL physical tables, which I find very helpful. However, I don't have the same for two key modules that we use: Project and Canadian Payroll. Does anybody have these to share? Don't have a system in front of me to check with, but the Canadian Payroll tables all start with CPY. You can print all of the details using Resources > Tables and selecting Canadian Payroll as your product and Project as the series. -- Lyle U Dwayne wrote: > I have and Excel mapping of GP tables to the SQL physical tables, > which I find very helpf...

Tough project,doc file explorer
Just as my tile imply ,i want to develop a doc file explorer.I am experienced towards this project.So would some kind guys give me some tips > Just as my tile imply ,i want to develop a doc file explorer.I am experienced > towards this project.So would some kind guys give me some tips How is it different from CFileDialog? Why not use it? --- Ajay "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message news:1161022593.998727.234980@m7g2000cwm.googlegroups.com... >> Just as my tile imply ,i want to develop a doc file explorer.I am >> experienced >> to...

Math library.
I need to use some math equations in my program in order to process my access file. How many math libraris I can get from .net,STL or others? I needs to do some statistics operations. That is why I want to search much more math libraries in MFC. Thanks in advanced. Lots. I found some, years ago, with a google search. Although many were products, there were some free ones. I used some source code for curve-fitting. joe On Wed, 27 Aug 2003 02:44:09 -0700, "sam" <s9443008@cc.ncu.edu.tw> wrote: > >I need to use some math equations in my program in order >to pr...

.NET Constants Class Library
I need to create a .net class library (dll) that contains nothing but a bunch of constants. It doesn't matter if it's VB.NET or C#, but it must be exposed to COM so that a legacy VB6 project can reference it and use the constants contained within the dll. Let's see if I can explain this clearly. I have created a C# dll which contains several classes and within those classes are the constants. Such as: using System; namespace MyConstantLib { public sealed class ItemConstants : CommonConstants { public static readonly Int32 CLASS_ITEM_BASE_CLASS = 901; ...

SmartHeap Library
I am printing a 16 pages publisher 2000 (SR-1) document on an HP Laserjet 5000. When I print 1 copy it is ok. But when I try to print another copy or more tan 1 copy at a time I get the following error message "SmartHeap Library. Out of memory. Pleae free some memory, then choose try retry" I have other document with hte same amount of pages that do not cause this error. What is going on? ...

Delay in finding remote library
I have a media server running Windows Media Player and usually play the music via one of two DLNA media players (a PS3 and a SoundBridge Radio), but when I try to pay the music from another PC via another copy of Windows Media Player it always takes several minutes to find the remote library. Why? ...

Library
My laptop is overloaded with pictures & music. I have moved all pictures to an external hard drive. My picture software now addresses itself to drive E. I have moved the music also but cannot re-define E as the library source without re-loading everything to C. help please Brian On Mon, 10 May 2010 14:19:01 -0700, Brian <Brian@discussions.microsoft.com> wrote: > I have moved the music also but cannot re-define E as the library source It's been a long time since I did this, but I think that all I had to do was place D:\Steves\Audio as the first entry in &q...

CRT (C Runtime Library)
Is that true the CRT (C runtime library) is much low level code compare to the C++ Standard Library? Since I saw the CRT mainipulate byte, floating point, search / sorting. So C++ programmer usually just use the C++ Standard Library instead using the much low level CRT?? It seem to me C++ Standard Library already includes everything for high level program like Game, Internet, Graphics destop applications. I don't really need CRT. So the CRT is mostly used by C programmer? June Lee wrote: > Is that true the CRT (C runtime library) is much low level code > compare to the C++ S...

Link to a published project
Hi, There is a way to create a html link to a published project on project server? (Example: project://server/project.published) Thank you, Mario Hi Mario, If you access the project via PWA, you'll find the link. The issue you'll have is making sure the view is correct, as this is defined in the URL. -- Regards, Ben. "Mario" wrote: > Hi, > > There is a way to create a html link to a published project on project > server? (Example: project://server/project.published) > > Thank you, > Mario I would like to create a ...