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

Similar Articles

[PageSpeed] 19

"Bill >" <<don't want more spam> wrote in message 
news:uqApdwCYJHA.5108@TK2MSFTNGP04.phx.gbl...
> Hi,
>
> I'm trying to create a library of one piece of code so the source can be 
> kept secret and only the header and the library file need to be included 
> in projects that use it. This is for use within my company.
>
> The library needs one dialog box to enter some data. I created the library 
> and put the dialog inside. I use this library in a project but the dialog 
> cannot be created. I get an error -1 from DoModal(). I remember seeing 
> once that a project can only have one resource file, so maybe my library 
> dialog is not getting included in the final executable. Am I right? Is 
> there a way to get it in there?
>
> I thought I could maybe make this a DLL, but 1. I've never done one before 
> and 2. I want to final executable to stand alone without a DLL I must also 
> supply.
>
> I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
> uphill battle. I finally got a dialog box to display but the first button 
> i tried to add doesn't display. Then i'm wondering how do I link the 
> button (or other controls) to the function or variable that I would 
> normally use Class Wizard to associate. Does anyone have any exmaple 
> program for this?
>
> Thanks,
>
> Bill

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

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

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

Anthony Wieser
Wieser Software Ltd

0
12/17/2008 9:53:25 AM
>The library needs one dialog box to enter some data. I created the library 
>and put the dialog inside. I use this library in a project but the dialog 
>cannot be created. I get an error -1 from DoModal().

Bill,

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

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

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

Dave
0
davidl7375 (2060)
12/17/2008 9:54:03 AM
"David Lowndes" <DavidL@example.invalid> wrote in message 
news:2sihk418ljnblkedmflb6vp7j6v3k5daaj@4ax.com...
> >The library needs one dialog box to enter some data. I created the 
> >library
>>and put the dialog inside. I use this library in a project but the dialog
>>cannot be created. I get an error -1 from DoModal().
>
> Bill,
>
> Static libraries don't contain any resources (but nothing in the IDE
> or tools tells you this). You either need to create a DLL (which can
> contain the dialog resource) or you'll have to include a copy of the
> dialog resource along with the static library in the projects that use
> it. The DLL option should be the easier and more manageable way to go.
>
>>I thought I could maybe make this a DLL, but 1. I've never done one before
>>and 2. I want to final executable to stand alone without a DLL I must also
>>supply.
>
> In that case you need to supply both the static library and dialog
> resource for inclusion in your projects.
>
> Dave

Dave,

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

Thanks,

Bill


0
Bill
12/17/2008 1:27:37 PM
>In your method, what is the best way to include the resource? I just make 
>the .rc file but it wants resource.h which has #defines that look like they 
>might conflict with the project that uses the library.

Bill,

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

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

Dave,

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

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

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

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

Thanks for any more tips.

Bill


0
Bill
12/17/2008 3:41:51 PM
See below...
On Wed, 17 Dec 2008 17:47:13 +0800, "Bill" <<don't want more spam>> wrote:

>Hi,
>
>I'm trying to create a library of one piece of code so the source can be 
>kept secret and only the header and the library file need to be included in 
>projects that use it. This is for use within my company.
****
This means you should deliver a DLL, or a COM component.  You can deliver a static
library, but as you will see below, this will not work if dialogs are involved.

What needs to be "secret" if it is used within the same company?  Everyone has signed the
same employment agreement...
****
>
>The library needs one dialog box to enter some data. I created the library 
>and put the dialog inside. I use this library in a project but the dialog 
>cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>that a project can only have one resource file, so maybe my library dialog 
>is not getting included in the final executable. Am I right? Is there a way 
>to get it in there?
****
Create your library as a DLL or COM component.  You cannot solve the problem if it
involves using a resource segment and a static library.  There is no way to "put the
dialog inside" a static library, short of using dialog templates and creating it "by
hand", but that has other problems.
****
>
>I thought I could maybe make this a DLL, but 1. I've never done one before 
>and 2. I want to final executable to stand alone without a DLL I must also 
>supply.
****
Not possible.  If you want a dialog, you have to do a DLL.

But why do you need the dialog in the library?  There's nothing "secret" about a dialog,
so why not just provide the dialog in source form with calls to the library?  Then anyone
can use it.  And it doesn't violate your idea of "secret"
****
>
>I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>uphill battle. I finally got a dialog box to display but the first button i 
>tried to add doesn't display. Then i'm wondering how do I link the button 
>(or other controls) to the function or variable that I would normally use 
>Class Wizard to associate. Does anyone have any exmaple program for this?
****
Read the rules about dialog templates and in particular the alignment requirements.
Putting a dialog template in means you cannot localize the product because this would
require a STRINGTABLE entry, and that limits its usefulness.

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

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

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

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

>
>Thanks,
>
>Bill
>
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/17/2008 4:51:14 PM
Give the dialog some huge ID.  It doesn't "guarantee" it is unique, just makes it
extremely unlikely there will be a collision.
				joe
On Wed, 17 Dec 2008 23:41:51 +0800, "Bill Brehm" <don't want spam> wrote:

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

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

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

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

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

Even if a static lib solution could be concocted, it would be a Bad 
Idea.  Think of the poor soul that will eventually come behind you to 
maintain your solution.
0
nothanks5518 (121)
12/17/2008 5:34:12 PM
Oh.  You want *maintainability* too?  I would have thought that the inability to do
localization would kill the idea.

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

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

>David Lowndes wrote:
>>> Would I have to include the library's .rc into the project's .rc? Would I 
>>> then just manually make sure the dialog ID is unique?
>> 
>> I think so - it's not something I've ever needed to do, I'd use the
>> DLL method.
>> 
>>> And in either case, isn't the the dialog ID already compiled in the library? 
>> 
>> Only if your library does it that way - have it passed in as a
>> parameter.
>> 
>> Dave
>
>Even if a static lib solution could be concocted, it would be a Bad 
>Idea.  Think of the poor soul that will eventually come behind you to 
>maintain your solution.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/17/2008 9:38:34 PM
Joseph M. Newcomer wrote:
> Oh.  You want *maintainability* too?  I would have thought that the inability to do
> localization would kill the idea.
> 
> It's bad enough the code has to be 'secret' within the company...
> 					joe
> 

I once worked for a large company that thought everything we did was 
subject to the Super Squirrel Secret Code.  Yes, it was a communication 
company - with the worst communication record in history!
0
nothanks5518 (121)
12/17/2008 9:58:09 PM
There are many valid reasons to protect code, but protecting it against the person in the
next cubicle raises issues about the competence of those setting the policies.
					joe

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

>Joseph M. Newcomer wrote:
>> Oh.  You want *maintainability* too?  I would have thought that the inability to do
>> localization would kill the idea.
>> 
>> It's bad enough the code has to be 'secret' within the company...
>> 					joe
>> 
>
>I once worked for a large company that thought everything we did was 
>subject to the Super Squirrel Secret Code.  Yes, it was a communication 
>company - with the worst communication record in history!
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/18/2008 1:13:48 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com...
> There are many valid reasons to protect code, but protecting it against 
> the person in the
> next cubicle raises issues about the competence of those setting the 
> policies.

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

-- David

0
dc2983 (3206)
12/18/2008 2:01:18 AM
First-rate people hire other first-rate people.  Second-rate people hire third-rate
people.

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

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

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

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

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

>"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
>news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com...
>> There are many valid reasons to protect code, but protecting it against 
>> the person in the
>> next cubicle raises issues about the competence of those setting the 
>> policies.
>
>Not really, it's quite common for managers to retain imbeciles on their 
>staff just to avoid admitting they hired the wrong person.  Managers want to 
>present a happy situation to their bosses.  And the code suffers, and the 
>competent developers suffer the most.
>
>-- David
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/18/2008 4:48:58 AM
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:lpkjk4lni2i3f0cf8oogd7mn5es9fi53q9@4ax.com...
> First-rate people hire other first-rate people.  Second-rate people hire 
> third-rate
> people.
>
> I once had the joy of working in an organization whose management aspired 
> to fifth-rate
> but didn't have much hope of getting there.  The reason I left was because 
> of the people
> they hired.
>
> When I was starting my own business, quite often I'd come downstairs, pick 
> up the mail,
> open the bills, and realize that I owed a great deal more money than I 
> had.  At this point
> a panic reaction would set in.  "Why am I doing this on my own?  Why don't 
> I go out and
> get a full-time job?"  To deal with this, I would lay down and think about 
> what my last
> two jobs had been like, and the feeling would go away.  Then I'd start 
> hustling, and land
> a short contract that paid the bills for a few months and created some 
> surplus.  Repeat
> for about four years...but the last 18 years have been much better.  In 
> Feb 2009 I will
> celebrate 22 years of being my own business [downside: the management is 
> still royally
> screwed up, but I am no longer entitled to complain about it...]
>
> Or, as I described it, "the reason I'm self-employed was two messy 
> divorces and an affair
> that didn't work out".  When I said this, someone who knew us said "But 
> you and <SO name
> here> are still together!" and I said "I'm not talking about my personal 
> life, I'm talking
> about my employment history".  One person understood completely because 
> it's the reason
> she's now single (but at the same job; for her it was personal life, not 
> employment).
>
> The best part is I don't have to deal with people who make these policies.
> joe
>

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

-- David 

0
dc2983 (3206)
12/18/2008 5:06:05 AM
Hi,

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

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

Bill < wrote:
> Hi,
> 
> I'm trying to create a library of one piece of code so the source can be 
> kept secret and only the header and the library file need to be included in 
> projects that use it. This is for use within my company.
> 
> The library needs one dialog box to enter some data. I created the library 
> and put the dialog inside. I use this library in a project but the dialog 
> cannot be created. I get an error -1 from DoModal(). I remember seeing once 
> that a project can only have one resource file, so maybe my library dialog 
> is not getting included in the final executable. Am I right? Is there a way 
> to get it in there?
> 
> I thought I could maybe make this a DLL, but 1. I've never done one before 
> and 2. I want to final executable to stand alone without a DLL I must also 
> supply.
> 
> I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
> uphill battle. I finally got a dialog box to display but the first button i 
> tried to add doesn't display. Then i'm wondering how do I link the button 
> (or other controls) to the function or variable that I would normally use 
> Class Wizard to associate. Does anyone have any exmaple program for this?
> 
> Thanks,
> 
> Bill
> 
> 
0
cpeters (15)
12/18/2008 10:04:03 PM
I was going to say the same thing. In fact, I may take exactly this approach 
with a current project.

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

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

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

"Colin Peters" <cpeters@coldmail.com> wrote in message 
news:494ac8d6_1@news.bluewin.ch...
> Hi,
>
> Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
> don't know what problems Joe was alluding to. Dialogs build from resources 
> are anyway build at runtime in a similar way. Look at 
> http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>
> As far as localisation, you could always access a text file of string 
> translations for the labels, and defautl to a language if no suitable file 
> is found. Quick and dirty at least. The problem with dlls and ActiveX is 
> when your interface changes your exes don't work until you relink. With a 
> static library if it's in it's in.
>
> Bill < wrote:
>> Hi,
>>
>> I'm trying to create a library of one piece of code so the source can be 
>> kept secret and only the header and the library file need to be included 
>> in projects that use it. This is for use within my company.
>>
>> The library needs one dialog box to enter some data. I created the 
>> library and put the dialog inside. I use this library in a project but 
>> the dialog cannot be created. I get an error -1 from DoModal(). I 
>> remember seeing once that a project can only have one resource file, so 
>> maybe my library dialog is not getting included in the final executable. 
>> Am I right? Is there a way to get it in there?
>>
>> I thought I could maybe make this a DLL, but 1. I've never done one 
>> before and 2. I want to final executable to stand alone without a DLL I 
>> must also supply.
>>
>> I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>> uphill battle. I finally got a dialog box to display but the first button 
>> i tried to add doesn't display. Then i'm wondering how do I link the 
>> button (or other controls) to the function or variable that I would 
>> normally use Class Wizard to associate. Does anyone have any exmaple 
>> program for this?
>>
>> Thanks,
>>
>> Bill
>> 
0
jwood (1292)
12/18/2008 10:47:44 PM
The hazards of localization are that you have to create additional mechanisms to achieve
it, such as the file of text.  This adds additional complexity to the creation,
management, and distribution of the product.  We did a localized product in MS-DOS that
used a separate file.  Not an experience I would want to repeat in Windows.

Note that for ActiveX, if you believe "the interface changes", then you are totally
clueless about writing ActiveX controls.  One of the key rules of ActiveX is that the
interface, once published, NEVER changes, and to violate this rule is a deep failure on
the part of the programmer.  Therefore, the interface cannot change.  
					joe
On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote:

>Hi,
>
>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>don't know what problems Joe was alluding to. Dialogs build from 
>resources are anyway build at runtime in a similar way. Look at 
>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>
>As far as localisation, you could always access a text file of string 
>translations for the labels, and defautl to a language if no suitable 
>file is found. Quick and dirty at least. The problem with dlls and 
>ActiveX is when your interface changes your exes don't work until you 
>relink. With a static library if it's in it's in.
>
>Bill < wrote:
>> Hi,
>> 
>> I'm trying to create a library of one piece of code so the source can be 
>> kept secret and only the header and the library file need to be included in 
>> projects that use it. This is for use within my company.
>> 
>> The library needs one dialog box to enter some data. I created the library 
>> and put the dialog inside. I use this library in a project but the dialog 
>> cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>> that a project can only have one resource file, so maybe my library dialog 
>> is not getting included in the final executable. Am I right? Is there a way 
>> to get it in there?
>> 
>> I thought I could maybe make this a DLL, but 1. I've never done one before 
>> and 2. I want to final executable to stand alone without a DLL I must also 
>> supply.
>> 
>> I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>> uphill battle. I finally got a dialog box to display but the first button i 
>> tried to add doesn't display. Then i'm wondering how do I link the button 
>> (or other controls) to the function or variable that I would normally use 
>> Class Wizard to associate. Does anyone have any exmaple program for this?
>> 
>> Thanks,
>> 
>> Bill
>> 
>> 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/19/2008 6:43:26 PM
My thoughts exactly, Jonathon. And I was able to solve the problem.

"Jonathan Wood" <jwood@softcircuits.com> wrote in message 
news:ePQloKWYJHA.5272@TK2MSFTNGP04.phx.gbl...
>I was going to say the same thing. In fact, I may take exactly this 
>approach with a current project.
>
> It has to do with shareware registration. There's no way I want this in a 
> separate DLL. Besides the fact that I prefer all my code in a single EXE 
> anyay, a DLL here would just make it so much easier for hackers.
>
> So I use a LIB file. And, for the dialog I need, I can just build it 
> dynamically.
>
> -- 
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
> "Colin Peters" <cpeters@coldmail.com> wrote in message 
> news:494ac8d6_1@news.bluewin.ch...
>> Hi,
>>
>> Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>> don't know what problems Joe was alluding to. Dialogs build from 
>> resources are anyway build at runtime in a similar way. Look at 
>> http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>>
>> As far as localisation, you could always access a text file of string 
>> translations for the labels, and defautl to a language if no suitable 
>> file is found. Quick and dirty at least. The problem with dlls and 
>> ActiveX is when your interface changes your exes don't work until you 
>> relink. With a static library if it's in it's in.
>>
>> Bill < wrote:
>>> Hi,
>>>
>>> I'm trying to create a library of one piece of code so the source can be 
>>> kept secret and only the header and the library file need to be included 
>>> in projects that use it. This is for use within my company.
>>>
>>> The library needs one dialog box to enter some data. I created the 
>>> library and put the dialog inside. I use this library in a project but 
>>> the dialog cannot be created. I get an error -1 from DoModal(). I 
>>> remember seeing once that a project can only have one resource file, so 
>>> maybe my library dialog is not getting included in the final executable. 
>>> Am I right? Is there a way to get it in there?
>>>
>>> I thought I could maybe make this a DLL, but 1. I've never done one 
>>> before and 2. I want to final executable to stand alone without a DLL I 
>>> must also supply.
>>>
>>> I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's 
>>> an uphill battle. I finally got a dialog box to display but the first 
>>> button i tried to add doesn't display. Then i'm wondering how do I link 
>>> the button (or other controls) to the function or variable that I would 
>>> normally use Class Wizard to associate. Does anyone have any exmaple 
>>> program for this?
>>>
>>> Thanks,
>>>
>>> Bill
>>> 


0
Bill
12/20/2008 2:42:37 AM
Joseph M. Newcomer wrote:
> The hazards of localization are that you have to create additional mechanisms to achieve
> it, such as the file of text.  This adds additional complexity to the creation,
> management, and distribution of the product.  We did a localized product in MS-DOS that
> used a separate file.  Not an experience I would want to repeat in Windows.
> 
> Note that for ActiveX, if you believe "the interface changes", then you are totally
> clueless about writing ActiveX controls.  One of the key rules of ActiveX is that the
> interface, once published, NEVER changes, and to violate this rule is a deep failure on
> the part of the programmer.  Therefore, the interface cannot change.

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

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

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



> 					joe
> On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote:
> 
> 
>>Hi,
>>
>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>>don't know what problems Joe was alluding to. Dialogs build from 
>>resources are anyway build at runtime in a similar way. Look at 
>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>>
>>As far as localisation, you could always access a text file of string 
>>translations for the labels, and defautl to a language if no suitable 
>>file is found. Quick and dirty at least. The problem with dlls and 
>>ActiveX is when your interface changes your exes don't work until you 
>>relink. With a static library if it's in it's in.
>>
>>Bill < wrote:
>>
>>>Hi,
>>>
>>>I'm trying to create a library of one piece of code so the source can be 
>>>kept secret and only the header and the library file need to be included in 
>>>projects that use it. This is for use within my company.
>>>
>>>The library needs one dialog box to enter some data. I created the library 
>>>and put the dialog inside. I use this library in a project but the dialog 
>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>>>that a project can only have one resource file, so maybe my library dialog 
>>>is not getting included in the final executable. Am I right? Is there a way 
>>>to get it in there?
>>>
>>>I thought I could maybe make this a DLL, but 1. I've never done one before 
>>>and 2. I want to final executable to stand alone without a DLL I must also 
>>>supply.
>>>
>>>I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>>>uphill battle. I finally got a dialog box to display but the first button i 
>>>tried to add doesn't display. Then i'm wondering how do I link the button 
>>>(or other controls) to the function or variable that I would normally use 
>>>Class Wizard to associate. Does anyone have any exmaple program for this?
>>>
>>>Thanks,
>>>
>>>Bill
>>>
>>>
> 
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm
0
cpeters (15)
12/20/2008 6:09:14 PM
See below...
On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:

>Joseph M. Newcomer wrote:
>> The hazards of localization are that you have to create additional mechanisms to achieve
>> it, such as the file of text.  This adds additional complexity to the creation,
>> management, and distribution of the product.  We did a localized product in MS-DOS that
>> used a separate file.  Not an experience I would want to repeat in Windows.
>> 
>> Note that for ActiveX, if you believe "the interface changes", then you are totally
>> clueless about writing ActiveX controls.  One of the key rules of ActiveX is that the
>> interface, once published, NEVER changes, and to violate this rule is a deep failure on
>> the part of the programmer.  Therefore, the interface cannot change.
>
>Nice try to put down another poster with different opinions to your own, 
>  but you'll have to do more than quote out of context to make any 
>headway here.
>
>You might live in a world where the specifications never change and you 
>implement a perfect solution on day 1. But I don't. Extra methods, 
>changed parameters, someone "improoving" a dll; these are my daily bread 
>and butter. In an ideal world once a (COM) interface is registered it 
>shouldn't change. But it can, and does. Madness, you might say, but it's 
>still a fact. And when you dynamically link it's out of your hands. 
>*You* might not be one who changed it, but your exe has to live with the 
>consequences. Static linkage gives you the peice of mind of knowing that 
>"when it's in, it's in."
*****
Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
modify the interface to an ActiveX control once the design has been set.  To change the
interface, you create a NEW interface.  This is how it works.  The third-party companies
that have failed to do this have created disasters.  So if it changes, it means you have
done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
screw up because you violated design rules.

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

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

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

So you get the interface you want and expect, if you do your job right.  If you choose to
do it wrong, you suffer the consequences.  A properly-done COM control will not have the
problems you describe.
******
>
>I'm not saying always staticly link, but I wouldn't rule out static 
>linkage just because you have to build dialogs dynamically. Once you've 
>done a couple it's really quite trivial.
*****
I simply don't understand the "single deck of cards was good enough for my
great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
gives you power and flexibility, and there should be no hesitation to program using modern
technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
it is fairly complex and I didn't feel like climbing the curve.  But I would have no
hesitation in using a DLL.  

Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
don't we just call all our executables a.exe and be done with it? [In case you don't know,
the cc compiler always created an exexcutable called a, unless you used the -o switch to
rename the executable file]
*****
>
>
>
>> 					joe
>> On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote:
>> 
>> 
>>>Hi,
>>>
>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>>>don't know what problems Joe was alluding to. Dialogs build from 
>>>resources are anyway build at runtime in a similar way. Look at 
>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>>>
>>>As far as localisation, you could always access a text file of string 
>>>translations for the labels, and defautl to a language if no suitable 
>>>file is found. Quick and dirty at least. The problem with dlls and 
>>>ActiveX is when your interface changes your exes don't work until you 
>>>relink. With a static library if it's in it's in.
>>>
>>>Bill < wrote:
>>>
>>>>Hi,
>>>>
>>>>I'm trying to create a library of one piece of code so the source can be 
>>>>kept secret and only the header and the library file need to be included in 
>>>>projects that use it. This is for use within my company.
>>>>
>>>>The library needs one dialog box to enter some data. I created the library 
>>>>and put the dialog inside. I use this library in a project but the dialog 
>>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>>>>that a project can only have one resource file, so maybe my library dialog 
>>>>is not getting included in the final executable. Am I right? Is there a way 
>>>>to get it in there?
>>>>
>>>>I thought I could maybe make this a DLL, but 1. I've never done one before 
>>>>and 2. I want to final executable to stand alone without a DLL I must also 
>>>>supply.
>>>>
>>>>I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>>>>uphill battle. I finally got a dialog box to display but the first button i 
>>>>tried to add doesn't display. Then i'm wondering how do I link the button 
>>>>(or other controls) to the function or variable that I would normally use 
>>>>Class Wizard to associate. Does anyone have any exmaple program for this?
>>>>
>>>>Thanks,
>>>>
>>>>Bill
>>>>
>>>>
>> 
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/22/2008 3:50:38 AM
Joe,

Read what I wrote.

Which was:
"In an ideal world once a (COM) interface is registered it
shouldn't change. But it can, and does. Madness, you might say, but it's
still a fact." "*You* might not be one who changed it, but your exe has 
to live with the consequences."

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

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

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

and

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

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

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

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

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


Joseph M. Newcomer wrote:
> See below...
> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:
> 
> 
>>Joseph M. Newcomer wrote:
>>
>>>The hazards of localization are that you have to create additional mechanisms to achieve
>>>it, such as the file of text.  This adds additional complexity to the creation,
>>>management, and distribution of the product.  We did a localized product in MS-DOS that
>>>used a separate file.  Not an experience I would want to repeat in Windows.
>>>
>>>Note that for ActiveX, if you believe "the interface changes", then you are totally
>>>clueless about writing ActiveX controls.  One of the key rules of ActiveX is that the
>>>interface, once published, NEVER changes, and to violate this rule is a deep failure on
>>>the part of the programmer.  Therefore, the interface cannot change.
>>
>>Nice try to put down another poster with different opinions to your own, 
>> but you'll have to do more than quote out of context to make any 
>>headway here.
>>
>>You might live in a world where the specifications never change and you 
>>implement a perfect solution on day 1. But I don't. Extra methods, 
>>changed parameters, someone "improoving" a dll; these are my daily bread 
>>and butter. In an ideal world once a (COM) interface is registered it 
>>shouldn't change. But it can, and does. Madness, you might say, but it's 
>>still a fact. And when you dynamically link it's out of your hands. 
>>*You* might not be one who changed it, but your exe has to live with the 
>>consequences. Static linkage gives you the peice of mind of knowing that 
>>"when it's in, it's in."
> 
> *****
> Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
> modify the interface to an ActiveX control once the design has been set.  To change the
> interface, you create a NEW interface.  This is how it works.  The third-party companies
> that have failed to do this have created disasters.  So if it changes, it means you have
> done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
> error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
> arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
> screw up because you violated design rules.
> 
> This is why COM interfaces are preferred to raw DLL interfaces if you want stability of
> the interface.
> 
> So of course I'll put down someone who doesn't know what they're doing and violate
> fundamental design rules of COM.  These have been established as the Right Way To Build
> COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder
> the caption "Interface Pointers and Interfaces")
> =========
> COM interfaces are immutable--You cannot define a new version of an old interface and give
> it the same identifier. Adding or removing methods of an interface or changing semantics
> creates a new interface, not a new version of an old interface. Therefore, a new interface
> cannot conflict with an old interface. However, objects can support multiple interfaces
> simultaneously and can expose interfaces that are successive revisions of an interface,
> with different identifiers. Thus, each interface is a separate contract, and systemwide
> objects need not be concerned about whether the version of the interface they are calling
> is the one they expect. The interface ID (IID) defines the interface contract explicitly
> and uniquely.
> ==========
> So why do you say this is "my opinion" when it is stated in the Microsoft documentation as
> one of the fundamental properties of a COM interface?  If you change the methods or add a
> method, you have violated one of the basic design requirements, and your change is
> therefore erroneous.  So you build bad code, don't be surprised if it fails.  Good code
> cannot fail, because if you update the interface, you create a new interface, and new code
> uses the new name; as it says above, you can support multiple interfaces.  Therefore,
> there is never a situation in which you have to recompile the client code to use the COM
> object.  It will always work with its registered COM object.  Or, the interface changes,
> and indeed you update the code, because your code needed that new interface, but all the
> old code continues to run.  Or fails because you have removed the interface, but then you
> know; you don't get access faults or other problems, because either the interface is
> supported, or it doesn't exist.
> 
> Sorry to disappoint you, but if you think you are allowed to change the interface specs in
> COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you that you are
> wrong.
> 
> So you get the interface you want and expect, if you do your job right.  If you choose to
> do it wrong, you suffer the consequences.  A properly-done COM control will not have the
> problems you describe.
> ******
> 
>>I'm not saying always staticly link, but I wouldn't rule out static 
>>linkage just because you have to build dialogs dynamically. Once you've 
>>done a couple it's really quite trivial.
> 
> *****
> I simply don't understand the "single deck of cards was good enough for my
> great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
> gives you power and flexibility, and there should be no hesitation to program using modern
> technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
> it is fairly complex and I didn't feel like climbing the curve.  But I would have no
> hesitation in using a DLL.  
> 
> Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
> basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
> don't we just call all our executables a.exe and be done with it? [In case you don't know,
> the cc compiler always created an exexcutable called a, unless you used the -o switch to
> rename the executable file]
> *****
> 
>>
>>
>>>					joe
>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>>>>don't know what problems Joe was alluding to. Dialogs build from 
>>>>resources are anyway build at runtime in a similar way. Look at 
>>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>>>>
>>>>As far as localisation, you could always access a text file of string 
>>>>translations for the labels, and defautl to a language if no suitable 
>>>>file is found. Quick and dirty at least. The problem with dlls and 
>>>>ActiveX is when your interface changes your exes don't work until you 
>>>>relink. With a static library if it's in it's in.
>>>>
>>>>Bill < wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I'm trying to create a library of one piece of code so the source can be 
>>>>>kept secret and only the header and the library file need to be included in 
>>>>>projects that use it. This is for use within my company.
>>>>>
>>>>>The library needs one dialog box to enter some data. I created the library 
>>>>>and put the dialog inside. I use this library in a project but the dialog 
>>>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>>>>>that a project can only have one resource file, so maybe my library dialog 
>>>>>is not getting included in the final executable. Am I right? Is there a way 
>>>>>to get it in there?
>>>>>
>>>>>I thought I could maybe make this a DLL, but 1. I've never done one before 
>>>>>and 2. I want to final executable to stand alone without a DLL I must also 
>>>>>supply.
>>>>>
>>>>>I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>>>>>uphill battle. I finally got a dialog box to display but the first button i 
>>>>>tried to add doesn't display. Then i'm wondering how do I link the button 
>>>>>(or other controls) to the function or variable that I would normally use 
>>>>>Class Wizard to associate. Does anyone have any exmaple program for this?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>Bill
>>>>>
>>>>>
>>>
>>>Joseph M. Newcomer [MVP]
>>>email: newcomer@flounder.com
>>>Web: http://www.flounder.com
>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
> 
> Joseph M. Newcomer [MVP]
> email: newcomer@flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm
0
cpeters (15)
12/23/2008 5:20:24 PM
See below...
On Tue, 23 Dec 2008 18:20:24 +0100, Colin Peters <cpeters@coldmail.com> wrote:

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

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

I did not say it was the ramblings of an idiot; I said it was a poor choice for a variety
of technical and user-oriented reasons.  
*****
>
>
>Joseph M. Newcomer wrote:
>> See below...
>> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote:
>> 
>> 
>>>Joseph M. Newcomer wrote:
>>>
>>>>The hazards of localization are that you have to create additional mechanisms to achieve
>>>>it, such as the file of text.  This adds additional complexity to the creation,
>>>>management, and distribution of the product.  We did a localized product in MS-DOS that
>>>>used a separate file.  Not an experience I would want to repeat in Windows.
>>>>
>>>>Note that for ActiveX, if you believe "the interface changes", then you are totally
>>>>clueless about writing ActiveX controls.  One of the key rules of ActiveX is that the
>>>>interface, once published, NEVER changes, and to violate this rule is a deep failure on
>>>>the part of the programmer.  Therefore, the interface cannot change.
>>>
>>>Nice try to put down another poster with different opinions to your own, 
>>> but you'll have to do more than quote out of context to make any 
>>>headway here.
>>>
>>>You might live in a world where the specifications never change and you 
>>>implement a perfect solution on day 1. But I don't. Extra methods, 
>>>changed parameters, someone "improoving" a dll; these are my daily bread 
>>>and butter. In an ideal world once a (COM) interface is registered it 
>>>shouldn't change. But it can, and does. Madness, you might say, but it's 
>>>still a fact. And when you dynamically link it's out of your hands. 
>>>*You* might not be one who changed it, but your exe has to live with the 
>>>consequences. Static linkage gives you the peice of mind of knowing that 
>>>"when it's in, it's in."
>> 
>> *****
>> Note that I said this specificallyl in reference to ActiveX controls.  It is erroneous to
>> modify the interface to an ActiveX control once the design has been set.  To change the
>> interface, you create a NEW interface.  This is how it works.  The third-party companies
>> that have failed to do this have created disasters.  So if it changes, it means you have
>> done the wrong thing.  Once it is released, it is frozen forever, and it is ALWAYS an
>> error to change it, no exceptions.  This is PRECISELY so the problem you mention cannot
>> arise.  So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you
>> screw up because you violated design rules.
>> 
>> This is why COM interfaces are preferred to raw DLL interfaces if you want stability of
>> the interface.
>> 
>> So of course I'll put down someone who doesn't know what they're doing and violate
>> fundamental design rules of COM.  These have been established as the Right Way To Build
>> COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder
>> the caption "Interface Pointers and Interfaces")
>> =========
>> COM interfaces are immutable--You cannot define a new version of an old interface and give
>> it the same identifier. Adding or removing methods of an interface or changing semantics
>> creates a new interface, not a new version of an old interface. Therefore, a new interface
>> cannot conflict with an old interface. However, objects can support multiple interfaces
>> simultaneously and can expose interfaces that are successive revisions of an interface,
>> with different identifiers. Thus, each interface is a separate contract, and systemwide
>> objects need not be concerned about whether the version of the interface they are calling
>> is the one they expect. The interface ID (IID) defines the interface contract explicitly
>> and uniquely.
>> ==========
>> So why do you say this is "my opinion" when it is stated in the Microsoft documentation as
>> one of the fundamental properties of a COM interface?  If you change the methods or add a
>> method, you have violated one of the basic design requirements, and your change is
>> therefore erroneous.  So you build bad code, don't be surprised if it fails.  Good code
>> cannot fail, because if you update the interface, you create a new interface, and new code
>> uses the new name; as it says above, you can support multiple interfaces.  Therefore,
>> there is never a situation in which you have to recompile the client code to use the COM
>> object.  It will always work with its registered COM object.  Or, the interface changes,
>> and indeed you update the code, because your code needed that new interface, but all the
>> old code continues to run.  Or fails because you have removed the interface, but then you
>> know; you don't get access faults or other problems, because either the interface is
>> supported, or it doesn't exist.
>> 
>> Sorry to disappoint you, but if you think you are allowed to change the interface specs in
>> COM, you are simply wrong.  Go argue with Microsoft.  Who will tell you that you are
>> wrong.
>> 
>> So you get the interface you want and expect, if you do your job right.  If you choose to
>> do it wrong, you suffer the consequences.  A properly-done COM control will not have the
>> problems you describe.
>> ******
>> 
>>>I'm not saying always staticly link, but I wouldn't rule out static 
>>>linkage just because you have to build dialogs dynamically. Once you've 
>>>done a couple it's really quite trivial.
>> 
>> *****
>> I simply don't understand the "single deck of cards was good enough for my
>> great-grandpappy, and by gum it's good enough for me!" attitude.  A DLL Is a tool that
>> gives you power and flexibility, and there should be no hesitation to program using modern
>> technology.  I feel a bit out-of-place because I *don't* use COM, and probably should; but
>> it is fairly complex and I didn't feel like climbing the curve.  But I would have no
>> hesitation in using a DLL.  
>> 
>> Static linking is occasionally, rarely, useful, and I've used it once or twice, but the
>> basic "I want just one .exe file" attitude seems out of step with modern practice.  Why
>> don't we just call all our executables a.exe and be done with it? [In case you don't know,
>> the cc compiler always created an exexcutable called a, unless you used the -o switch to
>> rename the executable file]
>> *****
>> 
>>>
>>>
>>>>					joe
>>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I 
>>>>>don't know what problems Joe was alluding to. Dialogs build from 
>>>>>resources are anyway build at runtime in a similar way. Look at 
>>>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example.
>>>>>
>>>>>As far as localisation, you could always access a text file of string 
>>>>>translations for the labels, and defautl to a language if no suitable 
>>>>>file is found. Quick and dirty at least. The problem with dlls and 
>>>>>ActiveX is when your interface changes your exes don't work until you 
>>>>>relink. With a static library if it's in it's in.
>>>>>
>>>>>Bill < wrote:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm trying to create a library of one piece of code so the source can be 
>>>>>>kept secret and only the header and the library file need to be included in 
>>>>>>projects that use it. This is for use within my company.
>>>>>>
>>>>>>The library needs one dialog box to enter some data. I created the library 
>>>>>>and put the dialog inside. I use this library in a project but the dialog 
>>>>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once 
>>>>>>that a project can only have one resource file, so maybe my library dialog 
>>>>>>is not getting included in the final executable. Am I right? Is there a way 
>>>>>>to get it in there?
>>>>>>
>>>>>>I thought I could maybe make this a DLL, but 1. I've never done one before 
>>>>>>and 2. I want to final executable to stand alone without a DLL I must also 
>>>>>>supply.
>>>>>>
>>>>>>I have been trying to InitModalIndirect()  from a DLGTEMPLATE but it's an 
>>>>>>uphill battle. I finally got a dialog box to display but the first button i 
>>>>>>tried to add doesn't display. Then i'm wondering how do I link the button 
>>>>>>(or other controls) to the function or variable that I would normally use 
>>>>>>Class Wizard to associate. Does anyone have any exmaple program for this?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Bill
>>>>>>
>>>>>>
>>>>
>>>>Joseph M. Newcomer [MVP]
>>>>email: newcomer@flounder.com
>>>>Web: http://www.flounder.com
>>>>MVP Tips: http://www.flounder.com/mvp_tips.htm
>> 
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
newcomer (15974)
12/23/2008 6:44:13 PM
And yet i'm happy with  my choice and I've moved on to the next challenge...

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


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

Similar Artilces:

Prevent access to Old Project Server
Using MSProject2003 (I know) I recently updated to a new server, communication to users about new server URL for access and login information has been delivered. Problem is that some users don't read their email and are still accessing and updating their projects on the old server. Is there any way to prevent users (not admin) from accessing the old server without removing (MSProjectServerUser and MSProjectUser) logins? Or, possibly add a warning message when access to old server is initiated? Reuter -- Remove all of the users from all of the security Groups in PWA...

Converting VC++ into mfc project
I took a sample from the MSDN and converted its make file into a standard VC project with a dsw file. Now I want to add mfc support. Is it possible and how? Is it possible to already existing modules? Can I convert into sdi and/or mdi project? Thanks in advance Gil Hi Gil, an old trick is to create a Project with does not have the feature you plan to add (e.g. no MFC support) with the Project wizard, then a second one whith the feature. Then, WINDIFF shows you exactly what you need to change in your existing application to add the feature there, too. Works also for converting fro...

problem about sphelper.h in MFC project created by VC++.NET
if I just use text to speech, it works. When I want to include file "sphelper.h" in my project, I got error messages such as "SPPHONEID can not convert to CSpDynamicString". Help!! Hello, I think you need to change the project setting, as follows: In C/C++, Language properties, change "Treat wchar_t as Built-in Type" to "No". Cheers Simon Jefferies jefferies_simon@hotmail.com "zabgwill" <wzswc@yahoo.com.cn> wrote in message news:058501c37839$891fd6a0$a501280a@phx.gbl... > if I just use text to speech, it works. When I want to &...

Turning an Access project into a stand alone package
Hi, I have developed for my company a document management programme in Access, which works well. I have now been requested to find out if this can be compiled/converted into a stand alone package, to be used in several offices around the world. I have been asked to give the proposed package a web-like feel and behaviour, instead of a classical Access form approach. My question: how can this be done: where to start; what programming language is best to use for this purpose; how to store data etc I am an autodidactic VBA programmer of a reasonable standard with no experience in othe...

how do I connect MS Project file (.mpp) to existing Sharept site
How do I connect a MS Project file (.mpp) to an existing SharePoint site? king8599 wrote: > How do I connect a MS Project file (.mpp) to an existing SharePoint site? This group is for discussion of Microsoft Publisher, not SharePoint or Project. I suggest you try one of the groups for Project and/or SharePoint. -- Ed Bennett - MVP Microsoft Publisher http://ed.mvps.org ...

To Do's don't appear in Project Center Entourage:2008
Is anyone else having this issue: I receive and email (associated with a project or not) and flag it for "To Do", I can also flag any "To Do" and link it to a project, but it does not appear as a task for that project. Help? Try asking in the Entourage forum. http://groups.google.com/group/microsoft.public.mac.office.entourage/topics edoug wrote: > Is anyone else having this issue: > > I receive and email (associated with a project or not) and flag it for > "To Do", I can also flag any "To Do" and link it to a project, but it > does no...

Reconcile Feature in Project Accounting
I would like more information as to when the reconcile feature should be used in Project Accounting. Is this something that should be done during month end? Kindly advise. According to the Project Accounting Administrator's Guide: Reconciling should not be necessary unless your data has been damaged, or some other unusual problem has occurred. Before reconciling quantities, back up all accounting data for your company. You must reconcile modules in the following order: • Sales Order Processing • Purchase Order Processing • Inventory • Project Accounting Hope this helps, rc &quo...

Project Biller Document
I would like to move/copy/whatever my modified invoice document from Sales to Project. Is this possible or do I need to recreate? Because the tables are different, you need to recreate. "Suzanne" <Suzanne@discussions.microsoft.com> wrote in message news:1FA429CB-1ECB-430F-A635-8395C49A5D40@microsoft.com... >I would like to move/copy/whatever my modified invoice document from Sales >to > Project. Is this possible or do I need to recreate? > > Thanks! "Charles Allen [MVP]" wrote: > Because the tables are different, you need to recreate. ...

Comparing Calendars between two project files
I need to compare the exceptions listed in several plans against a base template. I would like to try doing this by exporting the underlying tables into MS Access. Which table and fields do I need to home in on to list the working day exceptions? Hi Steve, I don't have Project 2007 handy right now but you can discover what fields/tables you can use to get exceptions through the Project 2007 SDK. http://msdn.microsoft.com/en-us/library/ms510779.aspx You can save the data from the reporting database through Report > Visual Reports, Save data, Save database. I h...

Project Accounting Combined History
Is there any way to automate the creation of the Project Accounting Combined History tables? I would like to automate so that it is created each morning. Is there a SQL script I can schedule? I am on GP 9. I'm not aware of a script already created but you could certainly create a job to run a SQL script to build the information. -- Charles Allen, MVP "Neil Haffey" wrote: > Is there any way to automate the creation of the Project Accounting Combined > History tables? I would like to automate so that it is created each morning. > Is there a SQL sc...

Portfolio Server
I am trying to figure out how I filter down my list of selected projects before I enter Optimizer. I have created a filter to select on a specfic workflow in builder, I apply it and it works correctly in Builder, but when I then select that portfolio to move forward into optimizer, it does not apply the same filter of the selected projects...so in essence I always get all of the project within a portfolio in optimizer. The documentation says it should work the way I have described...but it doesn't. Hello If you want to filter projects for optimizer you have to create the...

Problem upgrading project in VS2008
I upgraded my existing MFC app from VS2005 to VS2008. It uses ADO to connect to a sql server 2005 database. When compiled under VS2005 the connection to the server via the _ConnectionPtr interface opens virtually instantly. When compiled under VS2008, the first time in my app takes around 30 seconds to return from _ConnectionPtr::Open, though if I close the connection and then open it again it's back to near instant. And the app runs 100% fine thereafter - no crashes, freezes etc.. (I've had to increase the timeout on the connection, as otherwise it just timeouts. It's li...

Font library for Microsoft Office X
I would like to thin down my font list in Microsoft Office Word but cannot find the library. There is the main font library in the HD, the font library in the System and the font library in System 9. If I delete the entire main library, it doesn't change any of the fonts listed in the formatting palatte of Word. Is there a separate Microsoft Font collection hidden away somewhere? I would like to pare it down to a half-dozen fonts. Please help. On Sat, 19 Jun 2004 22:18:06 -0400, John wrote (in article <1ee0201c4566c$d26d6d60$a401280a@phx.gbl>): > I would like to thin down my fon...

RE: Understanding Project's Percent Complete vs. Percent Work Complete
Brian Kennemer wrote the subject-line article several years ago and was very informative/enlightening on how % Complete is computed, etc. However, in this article he showed a Microsoft Project view (Figure A) that had both "Work" and "Actual Work" rows in the detail lines for each resources on a specific task. Where can I find this view. I do need to enter actual hours worked per resource per day on their respective task thanks, David Hamil MaxVision 256-652-4322 David@MaxVision.com Perhaps what you seek is on the resource view or task usage view. Bot...

project
I spent all day setting up a new project and it has vanished.....really. I see the other 2 projects. I am an experienced computer user and have = had=20 Project crash once on me. In the documents folder I can still see the = name=20 of the project i the Office projects folder. There is no rge folder for = it=20 though when I do a search. Any suggestions? Molly Hi Molly, The first thing I do when my computer can't find files that I think it should be able to: run Apple Disk Utility First Aid to repair permissions. Please give that a try and see if that fixes things. -Jim -- Jim G...

charting a project overview
Is there a simple way to build a chart to show a overview of multiple projects including their milestones. For example I have Project A, B, C. Each project has milestones 1, 2, 3, 4, 5, 6 each with start and end dates. I would like to chart these projects where each project has a bar (or set of bars) and each milestone has a subbar (assuming no overlap). The x axis would be the dates. for example: My Projects: Project1 (show bar of milestone1) (bar of milestone2) (bar of milestone 3) .... project2 (show bar of milestone1) (bar of milestone2) (bar of milestone 3) .. project3 (s...

Do Libraries become a part of an MDE
If I biuld a database with a variety of active-x controls from different libraries and I build the front end into an MDE will the library files stay with it or do they still need to be loaded on each PC that this runs on? The libraries remain with the installed version of Access which is why many developers avoid ActiveX controls and use Late Binding. http://www.granite.ab.ca/access/latebinding.htm Programmer - wannaB wrote: >If I biuld a database with a variety of active-x controls from different >libraries and I build the front end into an MDE will the library files stay >with...

Impossible to connect onto Project Server
Hello, I re-installed Project Server 2007 SP2 + August CU on a server of my network. It works fine when I'm working on the server itself, but I cannot connect from another PC of the network. On the previous installs on the same network, I did not have any problem. What could be the cause of this connection issue? Thanks for help This is a multi-part message in MIME format. --------------000402010701000201040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Do you get any kind of error message when trying to connect? Did...

Project Server 2007 Hotfix dated 2/23/10
Need help in trying to determine what is actually being fixed in the newest hotfix they are the following first and second items in the kb article. Also, could someone let me know what the note applies to as well (that is the first item or the second item or both). Thanks!!!! 1. You accept updates for assignments in Microsoft Office Project 2007. In this case, the values for actual work and for actual overtime work differ from the values submitted by the resources. When you save and then publish the project, the resource timesheet on the My Tasks page shows the same incorrect...

A research about problems in virtual projects/teams
I=92m doing a research about problems in virtual projects/teams I have created a list of problems that member within virtual projects experience, according to Brake, Robb, Harvey, Herzog, Oertig Cascio, Lee-Kelly, Duarte and Snyder. My question is for managers and member who work in virtual team/group. Do you agree that the problems below are accurate, Or are there any problems that shouldn=92t be on the list, Or are there any problems that I should add to the list. Evident problems in virtual teams are: =95 Cultural differences =95 Project members=92 backgrounds =95 Lack or different exper...

Project Explrer
I have lost the Project Explorer windows in VB6. I have searched the Web and found many with the same problem but have not found any answer. What did I do and how can I undo it. Thanks Marv "M Wade" <nowhere@columbus.rr.com> wrote in message news:%23mkBPtE0KHA.4656@TK2MSFTNGP05.phx.gbl... >I have lost the Project Explorer windows in VB6. I have searched the Web >and found many with the same problem but have not found any answer. > > What did I do and how can I undo it. When you choose View | Project Explorer or hit Ctrl+R, does the IDE l...

GP Project Management
Hi, Can GP Project management module do the following 1) create and use project templates with a standard set of tasks? 2) assign resources, costs and dates to the tasks 3) track project progress TIA ...

Modify default MS Project Server 2007 Status Report
I would like to modify the default Status Report sections (Major Accomplishments, Objectives for the Next Period, Hot Issues) in Project Server 2007 to match those of my organization and to be applied to ALL published projects. This would eliminate the need to incorporate these changes for every new project. Is this possible? Are instructions available for doing this? Captain Kirk -- No, there is no default way to edit the default Status Report template. Sorry. -- Dale A. Howard [MVP] VP of Educational Services msProjectExperts http://www.msprojectexperts.com http:...

Project Server Workspace Permissions Question
I have created some Project Workspaces and users are able to access them fine. However, I created some additional lists on them: 1 List for tracking equipment and it is done in a datasheet view. The other one is a document library. In both cases, Team Members are not able to edit the lists. Now, I know that by default, you do not get the contribute list permission unless you have a task assigned, but I need all Team Members to have Contribute rights. So, how do I accomplish that? What server permission can I give or how can I work-around this? Two options I can think of: 1) As p...

library properties
Can anyone make this work (form MS Help) Theoretcially you can force people to enter document properties when they put a file into a library "Document library properties These are properties that are associated with documents in a document library (document library: A folder where a collection of files is shared and the files often use the same template. Each file in a library is associated with user-defined information that is displayed in the content listing for that library.) on a Web site or in a public folder. When you create a new document library, you can define on...