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 >" <<don't want more spam> wrote in message news:uqApdwCYJHA.5108@TK2MSFTNGP04.phx.gbl... > Hi, > > I'm trying to create a library of one piece of code so the source can be > kept secret and only the header and the library file need to be included > in projects that use it. This is for use within my company. > > The library needs one dialog box to enter some data. I created the library > and put the dialog inside. I use this library in a project but the dialog > cannot be created. I get an error -1 from DoModal(). I remember seeing > once that a project can only have one resource file, so maybe my library > dialog is not getting included in the final executable. Am I right? Is > there a way to get it in there? > > I thought I could maybe make this a DLL, but 1. I've never done one before > and 2. I want to final executable to stand alone without a DLL I must also > supply. > > I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an > uphill battle. I finally got a dialog box to display but the first button > i tried to add doesn't display. Then i'm wondering how do I link the > button (or other controls) to the function or variable that I would > normally use Class Wizard to associate. Does anyone have any exmaple > program for this? > > Thanks, > > Bill You could try building the dialog, etc outside the library project you're working on, then use FindResource and LoadResource to get at the data, which you could then encode for inclusion in your static library. I'd build it so the program in the end first tries to FindResource on the same resource though, so the end user can override the dialog. You probably want to use DLGTEMPLATEEX, and have a peek at Raymond Chen's excellent blog: https://blogs.msdn.com/oldnewthing/archive/2004/06/21/161375.aspx Anthony Wieser Wieser Software Ltd
>The library needs one dialog box to enter some data. I created the library >and put the dialog inside. I use this library in a project but the dialog >cannot be created. I get an error -1 from DoModal(). Bill, Static libraries don't contain any resources (but nothing in the IDE or tools tells you this). You either need to create a DLL (which can contain the dialog resource) or you'll have to include a copy of the dialog resource along with the static library in the projects that use it. The DLL option should be the easier and more manageable way to go. >I thought I could maybe make this a DLL, but 1. I've never done one before >and 2. I want to final executable to stand alone without a DLL I must also >supply. In that case you need to supply both the static library and dialog resource for inclusion in your projects. Dave
"David Lowndes" <DavidL@example.invalid> wrote in message news:2sihk418ljnblkedmflb6vp7j6v3k5daaj@4ax.com... > >The library needs one dialog box to enter some data. I created the > >library >>and put the dialog inside. I use this library in a project but the dialog >>cannot be created. I get an error -1 from DoModal(). > > Bill, > > Static libraries don't contain any resources (but nothing in the IDE > or tools tells you this). You either need to create a DLL (which can > contain the dialog resource) or you'll have to include a copy of the > dialog resource along with the static library in the projects that use > it. The DLL option should be the easier and more manageable way to go. > >>I thought I could maybe make this a DLL, but 1. I've never done one before >>and 2. I want to final executable to stand alone without a DLL I must also >>supply. > > In that case you need to supply both the static library and dialog > resource for inclusion in your projects. > > Dave Dave, In your method, what is the best way to include the resource? I just make the .rc file but it wants resource.h which has #defines that look like they might conflict with the project that uses the library. Thanks, Bill
![]() |
0 |
![]() |
>In your method, what is the best way to include the resource? I just make >the .rc file but it wants resource.h which has #defines that look like they >might conflict with the project that uses the library. Bill, Other than the dialog ID value, it shouldn't matter if the ID values for the controls in a dialog clash with other dialog control IDs. Dave
"David Lowndes" <DavidL@example.invalid> wrote in message news:q52ik4d9vtf7p8fum72f269o50362t7u8r@4ax.com... > >In your method, what is the best way to include the resource? I just make >>the .rc file but it wants resource.h which has #defines that look like >>they >>might conflict with the project that uses the library. > > Bill, > > Other than the dialog ID value, it shouldn't matter if the ID values > for the controls in a dialog clash with other dialog control IDs. > > Dave Dave, Sorry for being blur but so far i've just used the visual editor in a single resource project. So how do I do this? Would I have to include the library's .rc into the project's .rc? Would I then just manually make sure the dialog ID is unique? Or do I have to create the dialog visually in with the set of dialogs for the project? This would make sure the ID is unique. And in either case, isn't the the dialog ID already compiled in the library? That would mean the value has to be defined already at library compile time and therefore could still conflict, yes? Or is the dialog ID value not resolved until link time in which case the is can work? (I'm at home now, not at work where I can experiment on this.) Thanks for any more tips. Bill
![]() |
0 |
![]() |
See below... On Wed, 17 Dec 2008 17:47:13 +0800, "Bill" <<don't want more spam>> wrote: >Hi, > >I'm trying to create a library of one piece of code so the source can be >kept secret and only the header and the library file need to be included in >projects that use it. This is for use within my company. **** This means you should deliver a DLL, or a COM component. You can deliver a static library, but as you will see below, this will not work if dialogs are involved. What needs to be "secret" if it is used within the same company? Everyone has signed the same employment agreement... **** > >The library needs one dialog box to enter some data. I created the library >and put the dialog inside. I use this library in a project but the dialog >cannot be created. I get an error -1 from DoModal(). I remember seeing once >that a project can only have one resource file, so maybe my library dialog >is not getting included in the final executable. Am I right? Is there a way >to get it in there? **** Create your library as a DLL or COM component. You cannot solve the problem if it involves using a resource segment and a static library. There is no way to "put the dialog inside" a static library, short of using dialog templates and creating it "by hand", but that has other problems. **** > >I thought I could maybe make this a DLL, but 1. I've never done one before >and 2. I want to final executable to stand alone without a DLL I must also >supply. **** Not possible. If you want a dialog, you have to do a DLL. But why do you need the dialog in the library? There's nothing "secret" about a dialog, so why not just provide the dialog in source form with calls to the library? Then anyone can use it. And it doesn't violate your idea of "secret" **** > >I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >uphill battle. I finally got a dialog box to display but the first button i >tried to add doesn't display. Then i'm wondering how do I link the button >(or other controls) to the function or variable that I would normally use >Class Wizard to associate. Does anyone have any exmaple program for this? **** Read the rules about dialog templates and in particular the alignment requirements. Putting a dialog template in means you cannot localize the product because this would require a STRINGTABLE entry, and that limits its usefulness. You "link" the buttons in the same way you would normally: DDX_Control, ON_BN_CLICKED handlers, etc. You can't use a wizard to add them, but have you ever heard of a "text editor"? Or, to simplify things, create the dialog in the resource editor. Add everything in. Done. End of story. Then take the dialog template that is created, and embed it in your code. You can even write code that does a FindResource/LoadResource/LockResource and dumps the bits out, and you can then happily reformat them into a reasonable representation. You could even just do it as a DWORD array, as long as you keep a tool around that can read a real template and dump it out as a DWORD array as you need to make changes. Your problem is that you need to be lazier, and not ask "how can I do this?" but "how can I get some other tool to do this for me?" If you download the CD for our Win32 book (www.flounder.com/downloads.htm, 13MB) and look at the Pizza project, you will see a set of macros I wrote for constructing dialog templates. But I'd work on building a tool that would dump the dialog template. Probably would take less than an hour to write if you don't care about it looking pretty. But remember that with this method you lose all ability to do localization, because all the strings are hardwired. joe > >Thanks, > >Bill > Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
Give the dialog some huge ID. It doesn't "guarantee" it is unique, just makes it extremely unlikely there will be a collision. joe On Wed, 17 Dec 2008 23:41:51 +0800, "Bill Brehm" <don't want spam> wrote: > >"David Lowndes" <DavidL@example.invalid> wrote in message >news:q52ik4d9vtf7p8fum72f269o50362t7u8r@4ax.com... >> >In your method, what is the best way to include the resource? I just make >>>the .rc file but it wants resource.h which has #defines that look like >>>they >>>might conflict with the project that uses the library. >> >> Bill, >> >> Other than the dialog ID value, it shouldn't matter if the ID values >> for the controls in a dialog clash with other dialog control IDs. >> >> Dave > >Dave, > >Sorry for being blur but so far i've just used the visual editor in a single >resource project. So how do I do this? > >Would I have to include the library's .rc into the project's .rc? Would I >then just manually make sure the dialog ID is unique? > >Or do I have to create the dialog visually in with the set of dialogs for >the project? This would make sure the ID is unique. > >And in either case, isn't the the dialog ID already compiled in the library? >That would mean the value has to be defined already at library compile time >and therefore could still conflict, yes? Or is the dialog ID value not >resolved until link time in which case the is can work? (I'm at home now, >not at work where I can experiment on this.) > >Thanks for any more tips. > >Bill > Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
>Would I have to include the library's .rc into the project's .rc? Would I >then just manually make sure the dialog ID is unique? I think so - it's not something I've ever needed to do, I'd use the DLL method. >And in either case, isn't the the dialog ID already compiled in the library? Only if your library does it that way - have it passed in as a parameter. Dave
David Lowndes wrote: >> Would I have to include the library's .rc into the project's .rc? Would I >> then just manually make sure the dialog ID is unique? > > I think so - it's not something I've ever needed to do, I'd use the > DLL method. > >> And in either case, isn't the the dialog ID already compiled in the library? > > Only if your library does it that way - have it passed in as a > parameter. > > Dave Even if a static lib solution could be concocted, it would be a Bad Idea. Think of the poor soul that will eventually come behind you to maintain your solution.
Oh. You want *maintainability* too? I would have thought that the inability to do localization would kill the idea. It's bad enough the code has to be 'secret' within the company... joe On Wed, 17 Dec 2008 11:34:12 -0600, BobF <nothanks@spamfree.world> wrote: >David Lowndes wrote: >>> Would I have to include the library's .rc into the project's .rc? Would I >>> then just manually make sure the dialog ID is unique? >> >> I think so - it's not something I've ever needed to do, I'd use the >> DLL method. >> >>> And in either case, isn't the the dialog ID already compiled in the library? >> >> Only if your library does it that way - have it passed in as a >> parameter. >> >> Dave > >Even if a static lib solution could be concocted, it would be a Bad >Idea. Think of the poor soul that will eventually come behind you to >maintain your solution. Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer wrote: > Oh. You want *maintainability* too? I would have thought that the inability to do > localization would kill the idea. > > It's bad enough the code has to be 'secret' within the company... > joe > I once worked for a large company that thought everything we did was subject to the Super Squirrel Secret Code. Yes, it was a communication company - with the worst communication record in history!
There are many valid reasons to protect code, but protecting it against the person in the next cubicle raises issues about the competence of those setting the policies. joe On Wed, 17 Dec 2008 15:58:09 -0600, BobF <nothanks@spamfree.world> wrote: >Joseph M. Newcomer wrote: >> Oh. You want *maintainability* too? I would have thought that the inability to do >> localization would kill the idea. >> >> It's bad enough the code has to be 'secret' within the company... >> joe >> > >I once worked for a large company that thought everything we did was >subject to the Super Squirrel Secret Code. Yes, it was a communication >company - with the worst communication record in history! Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com... > There are many valid reasons to protect code, but protecting it against > the person in the > next cubicle raises issues about the competence of those setting the > policies. Not really, it's quite common for managers to retain imbeciles on their staff just to avoid admitting they hired the wrong person. Managers want to present a happy situation to their bosses. And the code suffers, and the competent developers suffer the most. -- David
First-rate people hire other first-rate people. Second-rate people hire third-rate people. I once had the joy of working in an organization whose management aspired to fifth-rate but didn't have much hope of getting there. The reason I left was because of the people they hired. When I was starting my own business, quite often I'd come downstairs, pick up the mail, open the bills, and realize that I owed a great deal more money than I had. At this point a panic reaction would set in. "Why am I doing this on my own? Why don't I go out and get a full-time job?" To deal with this, I would lay down and think about what my last two jobs had been like, and the feeling would go away. Then I'd start hustling, and land a short contract that paid the bills for a few months and created some surplus. Repeat for about four years...but the last 18 years have been much better. In Feb 2009 I will celebrate 22 years of being my own business [downside: the management is still royally screwed up, but I am no longer entitled to complain about it...] Or, as I described it, "the reason I'm self-employed was two messy divorces and an affair that didn't work out". When I said this, someone who knew us said "But you and <SO name here> are still together!" and I said "I'm not talking about my personal life, I'm talking about my employment history". One person understood completely because it's the reason she's now single (but at the same job; for her it was personal life, not employment). The best part is I don't have to deal with people who make these policies. joe On Wed, 17 Dec 2008 18:01:18 -0800, "David Ching" <dc@remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message >news:mq8jk4du2iro1cpc5lsabkkg7d3hndlu2b@4ax.com... >> There are many valid reasons to protect code, but protecting it against >> the person in the >> next cubicle raises issues about the competence of those setting the >> policies. > >Not really, it's quite common for managers to retain imbeciles on their >staff just to avoid admitting they hired the wrong person. Managers want to >present a happy situation to their bosses. And the code suffers, and the >competent developers suffer the most. > >-- David Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:lpkjk4lni2i3f0cf8oogd7mn5es9fi53q9@4ax.com... > First-rate people hire other first-rate people. Second-rate people hire > third-rate > people. > > I once had the joy of working in an organization whose management aspired > to fifth-rate > but didn't have much hope of getting there. The reason I left was because > of the people > they hired. > > When I was starting my own business, quite often I'd come downstairs, pick > up the mail, > open the bills, and realize that I owed a great deal more money than I > had. At this point > a panic reaction would set in. "Why am I doing this on my own? Why don't > I go out and > get a full-time job?" To deal with this, I would lay down and think about > what my last > two jobs had been like, and the feeling would go away. Then I'd start > hustling, and land > a short contract that paid the bills for a few months and created some > surplus. Repeat > for about four years...but the last 18 years have been much better. In > Feb 2009 I will > celebrate 22 years of being my own business [downside: the management is > still royally > screwed up, but I am no longer entitled to complain about it...] > > Or, as I described it, "the reason I'm self-employed was two messy > divorces and an affair > that didn't work out". When I said this, someone who knew us said "But > you and <SO name > here> are still together!" and I said "I'm not talking about my personal > life, I'm talking > about my employment history". One person understood completely because > it's the reason > she's now single (but at the same job; for her it was personal life, not > employment). > > The best part is I don't have to deal with people who make these policies. > joe > I don't know about you, but I can't be picky about whether my clients are fifth rate or first rate, the bottom line is I have to deal with some people who would ultimately benefit from locking down API's as is being suggested here. -- David
Hi, Just my 2p worth. Dynamically building dialogs isn't really so tricky. I don't know what problems Joe was alluding to. Dialogs build from resources are anyway build at runtime in a similar way. Look at http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. As far as localisation, you could always access a text file of string translations for the labels, and defautl to a language if no suitable file is found. Quick and dirty at least. The problem with dlls and ActiveX is when your interface changes your exes don't work until you relink. With a static library if it's in it's in. Bill < wrote: > Hi, > > I'm trying to create a library of one piece of code so the source can be > kept secret and only the header and the library file need to be included in > projects that use it. This is for use within my company. > > The library needs one dialog box to enter some data. I created the library > and put the dialog inside. I use this library in a project but the dialog > cannot be created. I get an error -1 from DoModal(). I remember seeing once > that a project can only have one resource file, so maybe my library dialog > is not getting included in the final executable. Am I right? Is there a way > to get it in there? > > I thought I could maybe make this a DLL, but 1. I've never done one before > and 2. I want to final executable to stand alone without a DLL I must also > supply. > > I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an > uphill battle. I finally got a dialog box to display but the first button i > tried to add doesn't display. Then i'm wondering how do I link the button > (or other controls) to the function or variable that I would normally use > Class Wizard to associate. Does anyone have any exmaple program for this? > > Thanks, > > Bill > >
I was going to say the same thing. In fact, I may take exactly this approach with a current project. It has to do with shareware registration. There's no way I want this in a separate DLL. Besides the fact that I prefer all my code in a single EXE anyay, a DLL here would just make it so much easier for hackers. So I use a LIB file. And, for the dialog I need, I can just build it dynamically. -- Jonathan Wood SoftCircuits Programming http://www.softcircuits.com "Colin Peters" <cpeters@coldmail.com> wrote in message news:494ac8d6_1@news.bluewin.ch... > Hi, > > Just my 2p worth. Dynamically building dialogs isn't really so tricky. I > don't know what problems Joe was alluding to. Dialogs build from resources > are anyway build at runtime in a similar way. Look at > http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. > > As far as localisation, you could always access a text file of string > translations for the labels, and defautl to a language if no suitable file > is found. Quick and dirty at least. The problem with dlls and ActiveX is > when your interface changes your exes don't work until you relink. With a > static library if it's in it's in. > > Bill < wrote: >> Hi, >> >> I'm trying to create a library of one piece of code so the source can be >> kept secret and only the header and the library file need to be included >> in projects that use it. This is for use within my company. >> >> The library needs one dialog box to enter some data. I created the >> library and put the dialog inside. I use this library in a project but >> the dialog cannot be created. I get an error -1 from DoModal(). I >> remember seeing once that a project can only have one resource file, so >> maybe my library dialog is not getting included in the final executable. >> Am I right? Is there a way to get it in there? >> >> I thought I could maybe make this a DLL, but 1. I've never done one >> before and 2. I want to final executable to stand alone without a DLL I >> must also supply. >> >> I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >> uphill battle. I finally got a dialog box to display but the first button >> i tried to add doesn't display. Then i'm wondering how do I link the >> button (or other controls) to the function or variable that I would >> normally use Class Wizard to associate. Does anyone have any exmaple >> program for this? >> >> Thanks, >> >> Bill >>
The hazards of localization are that you have to create additional mechanisms to achieve it, such as the file of text. This adds additional complexity to the creation, management, and distribution of the product. We did a localized product in MS-DOS that used a separate file. Not an experience I would want to repeat in Windows. Note that for ActiveX, if you believe "the interface changes", then you are totally clueless about writing ActiveX controls. One of the key rules of ActiveX is that the interface, once published, NEVER changes, and to violate this rule is a deep failure on the part of the programmer. Therefore, the interface cannot change. joe On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote: >Hi, > >Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >don't know what problems Joe was alluding to. Dialogs build from >resources are anyway build at runtime in a similar way. Look at >http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. > >As far as localisation, you could always access a text file of string >translations for the labels, and defautl to a language if no suitable >file is found. Quick and dirty at least. The problem with dlls and >ActiveX is when your interface changes your exes don't work until you >relink. With a static library if it's in it's in. > >Bill < wrote: >> Hi, >> >> I'm trying to create a library of one piece of code so the source can be >> kept secret and only the header and the library file need to be included in >> projects that use it. This is for use within my company. >> >> The library needs one dialog box to enter some data. I created the library >> and put the dialog inside. I use this library in a project but the dialog >> cannot be created. I get an error -1 from DoModal(). I remember seeing once >> that a project can only have one resource file, so maybe my library dialog >> is not getting included in the final executable. Am I right? Is there a way >> to get it in there? >> >> I thought I could maybe make this a DLL, but 1. I've never done one before >> and 2. I want to final executable to stand alone without a DLL I must also >> supply. >> >> I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >> uphill battle. I finally got a dialog box to display but the first button i >> tried to add doesn't display. Then i'm wondering how do I link the button >> (or other controls) to the function or variable that I would normally use >> Class Wizard to associate. Does anyone have any exmaple program for this? >> >> Thanks, >> >> Bill >> >> Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
My thoughts exactly, Jonathon. And I was able to solve the problem. "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:ePQloKWYJHA.5272@TK2MSFTNGP04.phx.gbl... >I was going to say the same thing. In fact, I may take exactly this >approach with a current project. > > It has to do with shareware registration. There's no way I want this in a > separate DLL. Besides the fact that I prefer all my code in a single EXE > anyay, a DLL here would just make it so much easier for hackers. > > So I use a LIB file. And, for the dialog I need, I can just build it > dynamically. > > -- > Jonathan Wood > SoftCircuits Programming > http://www.softcircuits.com > > "Colin Peters" <cpeters@coldmail.com> wrote in message > news:494ac8d6_1@news.bluewin.ch... >> Hi, >> >> Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >> don't know what problems Joe was alluding to. Dialogs build from >> resources are anyway build at runtime in a similar way. Look at >> http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. >> >> As far as localisation, you could always access a text file of string >> translations for the labels, and defautl to a language if no suitable >> file is found. Quick and dirty at least. The problem with dlls and >> ActiveX is when your interface changes your exes don't work until you >> relink. With a static library if it's in it's in. >> >> Bill < wrote: >>> Hi, >>> >>> I'm trying to create a library of one piece of code so the source can be >>> kept secret and only the header and the library file need to be included >>> in projects that use it. This is for use within my company. >>> >>> The library needs one dialog box to enter some data. I created the >>> library and put the dialog inside. I use this library in a project but >>> the dialog cannot be created. I get an error -1 from DoModal(). I >>> remember seeing once that a project can only have one resource file, so >>> maybe my library dialog is not getting included in the final executable. >>> Am I right? Is there a way to get it in there? >>> >>> I thought I could maybe make this a DLL, but 1. I've never done one >>> before and 2. I want to final executable to stand alone without a DLL I >>> must also supply. >>> >>> I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's >>> an uphill battle. I finally got a dialog box to display but the first >>> button i tried to add doesn't display. Then i'm wondering how do I link >>> the button (or other controls) to the function or variable that I would >>> normally use Class Wizard to associate. Does anyone have any exmaple >>> program for this? >>> >>> Thanks, >>> >>> Bill >>>
![]() |
0 |
![]() |
Joseph M. Newcomer wrote: > The hazards of localization are that you have to create additional mechanisms to achieve > it, such as the file of text. This adds additional complexity to the creation, > management, and distribution of the product. We did a localized product in MS-DOS that > used a separate file. Not an experience I would want to repeat in Windows. > > Note that for ActiveX, if you believe "the interface changes", then you are totally > clueless about writing ActiveX controls. One of the key rules of ActiveX is that the > interface, once published, NEVER changes, and to violate this rule is a deep failure on > the part of the programmer. Therefore, the interface cannot change. Nice try to put down another poster with different opinions to your own, but you'll have to do more than quote out of context to make any headway here. You might live in a world where the specifications never change and you implement a perfect solution on day 1. But I don't. Extra methods, changed parameters, someone "improoving" a dll; these are my daily bread and butter. In an ideal world once a (COM) interface is registered it shouldn't change. But it can, and does. Madness, you might say, but it's still a fact. And when you dynamically link it's out of your hands. *You* might not be one who changed it, but your exe has to live with the consequences. Static linkage gives you the peice of mind of knowing that "when it's in, it's in." I'm not saying always staticly link, but I wouldn't rule out static linkage just because you have to build dialogs dynamically. Once you've done a couple it's really quite trivial. > joe > On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote: > > >>Hi, >> >>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >>don't know what problems Joe was alluding to. Dialogs build from >>resources are anyway build at runtime in a similar way. Look at >>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. >> >>As far as localisation, you could always access a text file of string >>translations for the labels, and defautl to a language if no suitable >>file is found. Quick and dirty at least. The problem with dlls and >>ActiveX is when your interface changes your exes don't work until you >>relink. With a static library if it's in it's in. >> >>Bill < wrote: >> >>>Hi, >>> >>>I'm trying to create a library of one piece of code so the source can be >>>kept secret and only the header and the library file need to be included in >>>projects that use it. This is for use within my company. >>> >>>The library needs one dialog box to enter some data. I created the library >>>and put the dialog inside. I use this library in a project but the dialog >>>cannot be created. I get an error -1 from DoModal(). I remember seeing once >>>that a project can only have one resource file, so maybe my library dialog >>>is not getting included in the final executable. Am I right? Is there a way >>>to get it in there? >>> >>>I thought I could maybe make this a DLL, but 1. I've never done one before >>>and 2. I want to final executable to stand alone without a DLL I must also >>>supply. >>> >>>I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >>>uphill battle. I finally got a dialog box to display but the first button i >>>tried to add doesn't display. Then i'm wondering how do I link the button >>>(or other controls) to the function or variable that I would normally use >>>Class Wizard to associate. Does anyone have any exmaple program for this? >>> >>>Thanks, >>> >>>Bill >>> >>> > > Joseph M. Newcomer [MVP] > email: newcomer@flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
See below... On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote: >Joseph M. Newcomer wrote: >> The hazards of localization are that you have to create additional mechanisms to achieve >> it, such as the file of text. This adds additional complexity to the creation, >> management, and distribution of the product. We did a localized product in MS-DOS that >> used a separate file. Not an experience I would want to repeat in Windows. >> >> Note that for ActiveX, if you believe "the interface changes", then you are totally >> clueless about writing ActiveX controls. One of the key rules of ActiveX is that the >> interface, once published, NEVER changes, and to violate this rule is a deep failure on >> the part of the programmer. Therefore, the interface cannot change. > >Nice try to put down another poster with different opinions to your own, > but you'll have to do more than quote out of context to make any >headway here. > >You might live in a world where the specifications never change and you >implement a perfect solution on day 1. But I don't. Extra methods, >changed parameters, someone "improoving" a dll; these are my daily bread >and butter. In an ideal world once a (COM) interface is registered it >shouldn't change. But it can, and does. Madness, you might say, but it's >still a fact. And when you dynamically link it's out of your hands. >*You* might not be one who changed it, but your exe has to live with the >consequences. Static linkage gives you the peice of mind of knowing that >"when it's in, it's in." ***** Note that I said this specificallyl in reference to ActiveX controls. It is erroneous to modify the interface to an ActiveX control once the design has been set. To change the interface, you create a NEW interface. This is how it works. The third-party companies that have failed to do this have created disasters. So if it changes, it means you have done the wrong thing. Once it is released, it is frozen forever, and it is ALWAYS an error to change it, no exceptions. This is PRECISELY so the problem you mention cannot arise. So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you screw up because you violated design rules. This is why COM interfaces are preferred to raw DLL interfaces if you want stability of the interface. So of course I'll put down someone who doesn't know what they're doing and violate fundamental design rules of COM. These have been established as the Right Way To Build COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder the caption "Interface Pointers and Interfaces") ========= COM interfaces are immutable--You cannot define a new version of an old interface and give it the same identifier. Adding or removing methods of an interface or changing semantics creates a new interface, not a new version of an old interface. Therefore, a new interface cannot conflict with an old interface. However, objects can support multiple interfaces simultaneously and can expose interfaces that are successive revisions of an interface, with different identifiers. Thus, each interface is a separate contract, and systemwide objects need not be concerned about whether the version of the interface they are calling is the one they expect. The interface ID (IID) defines the interface contract explicitly and uniquely. ========== So why do you say this is "my opinion" when it is stated in the Microsoft documentation as one of the fundamental properties of a COM interface? If you change the methods or add a method, you have violated one of the basic design requirements, and your change is therefore erroneous. So you build bad code, don't be surprised if it fails. Good code cannot fail, because if you update the interface, you create a new interface, and new code uses the new name; as it says above, you can support multiple interfaces. Therefore, there is never a situation in which you have to recompile the client code to use the COM object. It will always work with its registered COM object. Or, the interface changes, and indeed you update the code, because your code needed that new interface, but all the old code continues to run. Or fails because you have removed the interface, but then you know; you don't get access faults or other problems, because either the interface is supported, or it doesn't exist. Sorry to disappoint you, but if you think you are allowed to change the interface specs in COM, you are simply wrong. Go argue with Microsoft. Who will tell you that you are wrong. So you get the interface you want and expect, if you do your job right. If you choose to do it wrong, you suffer the consequences. A properly-done COM control will not have the problems you describe. ****** > >I'm not saying always staticly link, but I wouldn't rule out static >linkage just because you have to build dialogs dynamically. Once you've >done a couple it's really quite trivial. ***** I simply don't understand the "single deck of cards was good enough for my great-grandpappy, and by gum it's good enough for me!" attitude. A DLL Is a tool that gives you power and flexibility, and there should be no hesitation to program using modern technology. I feel a bit out-of-place because I *don't* use COM, and probably should; but it is fairly complex and I didn't feel like climbing the curve. But I would have no hesitation in using a DLL. Static linking is occasionally, rarely, useful, and I've used it once or twice, but the basic "I want just one .exe file" attitude seems out of step with modern practice. Why don't we just call all our executables a.exe and be done with it? [In case you don't know, the cc compiler always created an exexcutable called a, unless you used the -o switch to rename the executable file] ***** > > > >> joe >> On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote: >> >> >>>Hi, >>> >>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >>>don't know what problems Joe was alluding to. Dialogs build from >>>resources are anyway build at runtime in a similar way. Look at >>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. >>> >>>As far as localisation, you could always access a text file of string >>>translations for the labels, and defautl to a language if no suitable >>>file is found. Quick and dirty at least. The problem with dlls and >>>ActiveX is when your interface changes your exes don't work until you >>>relink. With a static library if it's in it's in. >>> >>>Bill < wrote: >>> >>>>Hi, >>>> >>>>I'm trying to create a library of one piece of code so the source can be >>>>kept secret and only the header and the library file need to be included in >>>>projects that use it. This is for use within my company. >>>> >>>>The library needs one dialog box to enter some data. I created the library >>>>and put the dialog inside. I use this library in a project but the dialog >>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once >>>>that a project can only have one resource file, so maybe my library dialog >>>>is not getting included in the final executable. Am I right? Is there a way >>>>to get it in there? >>>> >>>>I thought I could maybe make this a DLL, but 1. I've never done one before >>>>and 2. I want to final executable to stand alone without a DLL I must also >>>>supply. >>>> >>>>I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >>>>uphill battle. I finally got a dialog box to display but the first button i >>>>tried to add doesn't display. Then i'm wondering how do I link the button >>>>(or other controls) to the function or variable that I would normally use >>>>Class Wizard to associate. Does anyone have any exmaple program for this? >>>> >>>>Thanks, >>>> >>>>Bill >>>> >>>> >> >> Joseph M. Newcomer [MVP] >> email: newcomer@flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
Joe, Read what I wrote. Which was: "In an ideal world once a (COM) interface is registered it shouldn't change. But it can, and does. Madness, you might say, but it's still a fact." "*You* might not be one who changed it, but your exe has to live with the consequences." Hopefully it's implicit that I was speaking from the point of view of the Active X consumer. There's nothing you can do to prevent an Active X supplier violating COM convention. Or in a general sense, a dll supplier doing the same. Both lead to the same effect; the consuming exe doesn't work correctly. There are almost no practical measures you can take to technically exclude this. You don't always work for the same company as the dll supplier. You don't always have jurisdiction over what gets "updated". You (jumped up on your high horse and) wrote: "So of course I'll put down someone who doesn't know what they're doing and violate fundamental design rules of COM." and "So you build bad code, don't be surprised if it fails." Yet it's pretty common to find a consuming exe coming to grief because of incomaptible dlls. This is sometimes refered to as "dll hell". You can be the best programmer in the world and still be hit by this. Now, one mechanism to help prevent this is static linking. There are drawbacks, but then everything is a balance. Ease of distribution, and the fact that no-one can (accidentally or otherwise) render your exe unrunable are advantages in my book. You seem to have spent some time quoting COM fundamentals and slinging insults without actually addressing the core issue from the original post. Namely, can you include a dialog in a static lib (which you can, albeit one coded entirely in a function rather than built from a resource), and what are the pros and cons thereof. It seems that you aren't very good at accepting alternative opinions. There's the Joe-way, and everything else must be the ramblings of an idiot. Maybe this is why you keep back the threat to "walk away" from "fifth-rate clients". Ultimately, we all have that choice, I suppose. But I've found I've got the most out of projects where at first glance things were never going to work. But then through compromise and innovation (and I admit, a bit of head-banging) things did actually work. Threatening to take the ball home is a bit childish, in my opinion. Joseph M. Newcomer wrote: > See below... > On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote: > > >>Joseph M. Newcomer wrote: >> >>>The hazards of localization are that you have to create additional mechanisms to achieve >>>it, such as the file of text. This adds additional complexity to the creation, >>>management, and distribution of the product. We did a localized product in MS-DOS that >>>used a separate file. Not an experience I would want to repeat in Windows. >>> >>>Note that for ActiveX, if you believe "the interface changes", then you are totally >>>clueless about writing ActiveX controls. One of the key rules of ActiveX is that the >>>interface, once published, NEVER changes, and to violate this rule is a deep failure on >>>the part of the programmer. Therefore, the interface cannot change. >> >>Nice try to put down another poster with different opinions to your own, >> but you'll have to do more than quote out of context to make any >>headway here. >> >>You might live in a world where the specifications never change and you >>implement a perfect solution on day 1. But I don't. Extra methods, >>changed parameters, someone "improoving" a dll; these are my daily bread >>and butter. In an ideal world once a (COM) interface is registered it >>shouldn't change. But it can, and does. Madness, you might say, but it's >>still a fact. And when you dynamically link it's out of your hands. >>*You* might not be one who changed it, but your exe has to live with the >>consequences. Static linkage gives you the peice of mind of knowing that >>"when it's in, it's in." > > ***** > Note that I said this specificallyl in reference to ActiveX controls. It is erroneous to > modify the interface to an ActiveX control once the design has been set. To change the > interface, you create a NEW interface. This is how it works. The third-party companies > that have failed to do this have created disasters. So if it changes, it means you have > done the wrong thing. Once it is released, it is frozen forever, and it is ALWAYS an > error to change it, no exceptions. This is PRECISELY so the problem you mention cannot > arise. So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you > screw up because you violated design rules. > > This is why COM interfaces are preferred to raw DLL interfaces if you want stability of > the interface. > > So of course I'll put down someone who doesn't know what they're doing and violate > fundamental design rules of COM. These have been established as the Right Way To Build > COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder > the caption "Interface Pointers and Interfaces") > ========= > COM interfaces are immutable--You cannot define a new version of an old interface and give > it the same identifier. Adding or removing methods of an interface or changing semantics > creates a new interface, not a new version of an old interface. Therefore, a new interface > cannot conflict with an old interface. However, objects can support multiple interfaces > simultaneously and can expose interfaces that are successive revisions of an interface, > with different identifiers. Thus, each interface is a separate contract, and systemwide > objects need not be concerned about whether the version of the interface they are calling > is the one they expect. The interface ID (IID) defines the interface contract explicitly > and uniquely. > ========== > So why do you say this is "my opinion" when it is stated in the Microsoft documentation as > one of the fundamental properties of a COM interface? If you change the methods or add a > method, you have violated one of the basic design requirements, and your change is > therefore erroneous. So you build bad code, don't be surprised if it fails. Good code > cannot fail, because if you update the interface, you create a new interface, and new code > uses the new name; as it says above, you can support multiple interfaces. Therefore, > there is never a situation in which you have to recompile the client code to use the COM > object. It will always work with its registered COM object. Or, the interface changes, > and indeed you update the code, because your code needed that new interface, but all the > old code continues to run. Or fails because you have removed the interface, but then you > know; you don't get access faults or other problems, because either the interface is > supported, or it doesn't exist. > > Sorry to disappoint you, but if you think you are allowed to change the interface specs in > COM, you are simply wrong. Go argue with Microsoft. Who will tell you that you are > wrong. > > So you get the interface you want and expect, if you do your job right. If you choose to > do it wrong, you suffer the consequences. A properly-done COM control will not have the > problems you describe. > ****** > >>I'm not saying always staticly link, but I wouldn't rule out static >>linkage just because you have to build dialogs dynamically. Once you've >>done a couple it's really quite trivial. > > ***** > I simply don't understand the "single deck of cards was good enough for my > great-grandpappy, and by gum it's good enough for me!" attitude. A DLL Is a tool that > gives you power and flexibility, and there should be no hesitation to program using modern > technology. I feel a bit out-of-place because I *don't* use COM, and probably should; but > it is fairly complex and I didn't feel like climbing the curve. But I would have no > hesitation in using a DLL. > > Static linking is occasionally, rarely, useful, and I've used it once or twice, but the > basic "I want just one .exe file" attitude seems out of step with modern practice. Why > don't we just call all our executables a.exe and be done with it? [In case you don't know, > the cc compiler always created an exexcutable called a, unless you used the -o switch to > rename the executable file] > ***** > >> >> >>> joe >>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote: >>> >>> >>> >>>>Hi, >>>> >>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >>>>don't know what problems Joe was alluding to. Dialogs build from >>>>resources are anyway build at runtime in a similar way. Look at >>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. >>>> >>>>As far as localisation, you could always access a text file of string >>>>translations for the labels, and defautl to a language if no suitable >>>>file is found. Quick and dirty at least. The problem with dlls and >>>>ActiveX is when your interface changes your exes don't work until you >>>>relink. With a static library if it's in it's in. >>>> >>>>Bill < wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I'm trying to create a library of one piece of code so the source can be >>>>>kept secret and only the header and the library file need to be included in >>>>>projects that use it. This is for use within my company. >>>>> >>>>>The library needs one dialog box to enter some data. I created the library >>>>>and put the dialog inside. I use this library in a project but the dialog >>>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once >>>>>that a project can only have one resource file, so maybe my library dialog >>>>>is not getting included in the final executable. Am I right? Is there a way >>>>>to get it in there? >>>>> >>>>>I thought I could maybe make this a DLL, but 1. I've never done one before >>>>>and 2. I want to final executable to stand alone without a DLL I must also >>>>>supply. >>>>> >>>>>I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >>>>>uphill battle. I finally got a dialog box to display but the first button i >>>>>tried to add doesn't display. Then i'm wondering how do I link the button >>>>>(or other controls) to the function or variable that I would normally use >>>>>Class Wizard to associate. Does anyone have any exmaple program for this? >>>>> >>>>>Thanks, >>>>> >>>>>Bill >>>>> >>>>> >>> >>>Joseph M. Newcomer [MVP] >>>email: newcomer@flounder.com >>>Web: http://www.flounder.com >>>MVP Tips: http://www.flounder.com/mvp_tips.htm > > Joseph M. Newcomer [MVP] > email: newcomer@flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
See below... On Tue, 23 Dec 2008 18:20:24 +0100, Colin Peters <cpeters@coldmail.com> wrote: >Joe, > >Read what I wrote. > >Which was: >"In an ideal world once a (COM) interface is registered it >shouldn't change. But it can, and does. Madness, you might say, but it's >still a fact." "*You* might not be one who changed it, but your exe has >to live with the consequences." **** Where does the Microsoft documentation say "The interface is immutable unless you feel it shouldn't be, because you don't believe that this requirement is relevant"? Sorry, if you ignore the basic principles of COM design, it won't work right, and that is YOUR fault for screwing up. It is, by defnition, an error to change an ActiveX component interface. If someone does, they screwed up, and they need to be dumped on for doing something stupid. **** > >Hopefully it's implicit that I was speaking from the point of view of >the Active X consumer. There's nothing you can do to prevent an Active X >supplier violating COM convention. Or in a general sense, a dll supplier >doing the same. Both lead to the same effect; the consuming exe doesn't >work correctly. There are almost no practical measures you can take to >technically exclude this. You don't always work for the same company as >the dll supplier. You don't always have jurisdiction over what gets >"updated". **** ]Actually, there are several things you can do when an ActiveX supplier violates COM specs, such as telling them they are stupid and irresponsible, and even finding an alternative supplier. Blasting them in blogs. Ranting at their tech support. What you are saying is "People screw up, and therefore we cannot possibly consider building an interface, WHERE WE ARE THE SUPPLIER, because some other supplier might screw up some other component". The answer is simple: behave responsibly, and your components will not suffer from this, and therefore, you should not reject a solution because you will do it correctly. **** > >You (jumped up on your high horse and) wrote: > >"So of course I'll put down someone who doesn't know what they're doing >and violate fundamental design rules of COM." > >and > >"So you build bad code, don't be surprised if it fails." **** Yep. Bad code fails. And it is part of *my* responsibility to point out to people who behave stupidly and irresponsibly that they are behaving stupid and irresponsibly. **** > >Yet it's pretty common to find a consuming exe coming to grief because >of incomaptible dlls. This is sometimes refered to as "dll hell". You >can be the best programmer in the world and still be hit by this. **** Incompatible DLLs are a different question than COM interfaces, which is what I was talking about. **** > >Now, one mechanism to help prevent this is static linking. There are >drawbacks, but then everything is a balance. Ease of distribution, and >the fact that no-one can (accidentally or otherwise) render your exe >unrunable are advantages in my book. ***** Static linking works fine until you are given a DLL or COM component, then it no longer is worth talking about. Note also that you no longer have the ability to replace components, or upgrade them, without a complete relink and redistribution of the entire file, which is a significant disadvantage. **** > >You seem to have spent some time quoting COM fundamentals and slinging >insults without actually addressing the core issue from the original >post. Namely, can you include a dialog in a static lib (which you can, >albeit one coded entirely in a function rather than built from a >resource), and what are the pros and cons thereof. ***** I already answered that in a number of ways, including pointing the OP to at code I wrote to allow the creation of dialog templates. ***** > >It seems that you aren't very good at accepting alternative opinions. >There's the Joe-way, and everything else must be the ramblings of an >idiot. Maybe this is why you keep back the threat to "walk away" from >"fifth-rate clients". Ultimately, we all have that choice, I suppose. >But I've found I've got the most out of projects where at first glance >things were never going to work. But then through compromise and >innovation (and I admit, a bit of head-banging) things did actually >work. Threatening to take the ball home is a bit childish, in my opinion. ***** There are downsides to several solutions. I pointed out that creating templates mean that there is no way to effectively localize the code without introducing additional mechanisms. Note that localization has other implications, such as the fact that in some languages the labels (static controls) and input (edit controls, combo boxes) among others have to be resized to allow for longer words. That won't happen with hand-crafted code. I did not say it was the ramblings of an idiot; I said it was a poor choice for a variety of technical and user-oriented reasons. ***** > > >Joseph M. Newcomer wrote: >> See below... >> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> wrote: >> >> >>>Joseph M. Newcomer wrote: >>> >>>>The hazards of localization are that you have to create additional mechanisms to achieve >>>>it, such as the file of text. This adds additional complexity to the creation, >>>>management, and distribution of the product. We did a localized product in MS-DOS that >>>>used a separate file. Not an experience I would want to repeat in Windows. >>>> >>>>Note that for ActiveX, if you believe "the interface changes", then you are totally >>>>clueless about writing ActiveX controls. One of the key rules of ActiveX is that the >>>>interface, once published, NEVER changes, and to violate this rule is a deep failure on >>>>the part of the programmer. Therefore, the interface cannot change. >>> >>>Nice try to put down another poster with different opinions to your own, >>> but you'll have to do more than quote out of context to make any >>>headway here. >>> >>>You might live in a world where the specifications never change and you >>>implement a perfect solution on day 1. But I don't. Extra methods, >>>changed parameters, someone "improoving" a dll; these are my daily bread >>>and butter. In an ideal world once a (COM) interface is registered it >>>shouldn't change. But it can, and does. Madness, you might say, but it's >>>still a fact. And when you dynamically link it's out of your hands. >>>*You* might not be one who changed it, but your exe has to live with the >>>consequences. Static linkage gives you the peice of mind of knowing that >>>"when it's in, it's in." >> >> ***** >> Note that I said this specificallyl in reference to ActiveX controls. It is erroneous to >> modify the interface to an ActiveX control once the design has been set. To change the >> interface, you create a NEW interface. This is how it works. The third-party companies >> that have failed to do this have created disasters. So if it changes, it means you have >> done the wrong thing. Once it is released, it is frozen forever, and it is ALWAYS an >> error to change it, no exceptions. This is PRECISELY so the problem you mention cannot >> arise. So don't blame me if you use the mechanisms incorrectly; it isn't my fault if you >> screw up because you violated design rules. >> >> This is why COM interfaces are preferred to raw DLL interfaces if you want stability of >> the interface. >> >> So of course I'll put down someone who doesn't know what they're doing and violate >> fundamental design rules of COM. These have been established as the Right Way To Build >> COM Controls, and obviously you missed this critical paragraph in the MSDN (which is upder >> the caption "Interface Pointers and Interfaces") >> ========= >> COM interfaces are immutable--You cannot define a new version of an old interface and give >> it the same identifier. Adding or removing methods of an interface or changing semantics >> creates a new interface, not a new version of an old interface. Therefore, a new interface >> cannot conflict with an old interface. However, objects can support multiple interfaces >> simultaneously and can expose interfaces that are successive revisions of an interface, >> with different identifiers. Thus, each interface is a separate contract, and systemwide >> objects need not be concerned about whether the version of the interface they are calling >> is the one they expect. The interface ID (IID) defines the interface contract explicitly >> and uniquely. >> ========== >> So why do you say this is "my opinion" when it is stated in the Microsoft documentation as >> one of the fundamental properties of a COM interface? If you change the methods or add a >> method, you have violated one of the basic design requirements, and your change is >> therefore erroneous. So you build bad code, don't be surprised if it fails. Good code >> cannot fail, because if you update the interface, you create a new interface, and new code >> uses the new name; as it says above, you can support multiple interfaces. Therefore, >> there is never a situation in which you have to recompile the client code to use the COM >> object. It will always work with its registered COM object. Or, the interface changes, >> and indeed you update the code, because your code needed that new interface, but all the >> old code continues to run. Or fails because you have removed the interface, but then you >> know; you don't get access faults or other problems, because either the interface is >> supported, or it doesn't exist. >> >> Sorry to disappoint you, but if you think you are allowed to change the interface specs in >> COM, you are simply wrong. Go argue with Microsoft. Who will tell you that you are >> wrong. >> >> So you get the interface you want and expect, if you do your job right. If you choose to >> do it wrong, you suffer the consequences. A properly-done COM control will not have the >> problems you describe. >> ****** >> >>>I'm not saying always staticly link, but I wouldn't rule out static >>>linkage just because you have to build dialogs dynamically. Once you've >>>done a couple it's really quite trivial. >> >> ***** >> I simply don't understand the "single deck of cards was good enough for my >> great-grandpappy, and by gum it's good enough for me!" attitude. A DLL Is a tool that >> gives you power and flexibility, and there should be no hesitation to program using modern >> technology. I feel a bit out-of-place because I *don't* use COM, and probably should; but >> it is fairly complex and I didn't feel like climbing the curve. But I would have no >> hesitation in using a DLL. >> >> Static linking is occasionally, rarely, useful, and I've used it once or twice, but the >> basic "I want just one .exe file" attitude seems out of step with modern practice. Why >> don't we just call all our executables a.exe and be done with it? [In case you don't know, >> the cc compiler always created an exexcutable called a, unless you used the -o switch to >> rename the executable file] >> ***** >> >>> >>> >>>> joe >>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. I >>>>>don't know what problems Joe was alluding to. Dialogs build from >>>>>resources are anyway build at runtime in a similar way. Look at >>>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an example. >>>>> >>>>>As far as localisation, you could always access a text file of string >>>>>translations for the labels, and defautl to a language if no suitable >>>>>file is found. Quick and dirty at least. The problem with dlls and >>>>>ActiveX is when your interface changes your exes don't work until you >>>>>relink. With a static library if it's in it's in. >>>>> >>>>>Bill < wrote: >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>I'm trying to create a library of one piece of code so the source can be >>>>>>kept secret and only the header and the library file need to be included in >>>>>>projects that use it. This is for use within my company. >>>>>> >>>>>>The library needs one dialog box to enter some data. I created the library >>>>>>and put the dialog inside. I use this library in a project but the dialog >>>>>>cannot be created. I get an error -1 from DoModal(). I remember seeing once >>>>>>that a project can only have one resource file, so maybe my library dialog >>>>>>is not getting included in the final executable. Am I right? Is there a way >>>>>>to get it in there? >>>>>> >>>>>>I thought I could maybe make this a DLL, but 1. I've never done one before >>>>>>and 2. I want to final executable to stand alone without a DLL I must also >>>>>>supply. >>>>>> >>>>>>I have been trying to InitModalIndirect() from a DLGTEMPLATE but it's an >>>>>>uphill battle. I finally got a dialog box to display but the first button i >>>>>>tried to add doesn't display. Then i'm wondering how do I link the button >>>>>>(or other controls) to the function or variable that I would normally use >>>>>>Class Wizard to associate. Does anyone have any exmaple program for this? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Bill >>>>>> >>>>>> >>>> >>>>Joseph M. Newcomer [MVP] >>>>email: newcomer@flounder.com >>>>Web: http://www.flounder.com >>>>MVP Tips: http://www.flounder.com/mvp_tips.htm >> >> Joseph M. Newcomer [MVP] >> email: newcomer@flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
And yet i'm happy with my choice and I've moved on to the next challenge... "Joseph M. Newcomer" <newcomer@flounder.com> wrote in message news:1qb2l4lk0feidrc8u09i97r9nad809fice@4ax.com... > See below... > On Tue, 23 Dec 2008 18:20:24 +0100, Colin Peters <cpeters@coldmail.com> > wrote: > >>Joe, >> >>Read what I wrote. >> >>Which was: >>"In an ideal world once a (COM) interface is registered it >>shouldn't change. But it can, and does. Madness, you might say, but it's >>still a fact." "*You* might not be one who changed it, but your exe has >>to live with the consequences." > **** > Where does the Microsoft documentation say "The interface is immutable > unless you feel it > shouldn't be, because you don't believe that this requirement is > relevant"? Sorry, if you > ignore the basic principles of COM design, it won't work right, and that > is YOUR fault for > screwing up. It is, by defnition, an error to change an ActiveX component > interface. If > someone does, they screwed up, and they need to be dumped on for doing > something stupid. > **** >> >>Hopefully it's implicit that I was speaking from the point of view of >>the Active X consumer. There's nothing you can do to prevent an Active X >>supplier violating COM convention. Or in a general sense, a dll supplier >>doing the same. Both lead to the same effect; the consuming exe doesn't >>work correctly. There are almost no practical measures you can take to >>technically exclude this. You don't always work for the same company as >>the dll supplier. You don't always have jurisdiction over what gets >>"updated". > **** > ]Actually, there are several things you can do when an ActiveX supplier > violates COM > specs, such as telling them they are stupid and irresponsible, and even > finding an > alternative supplier. Blasting them in blogs. Ranting at their tech > support. What you > are saying is "People screw up, and therefore we cannot possibly consider > building an > interface, WHERE WE ARE THE SUPPLIER, because some other supplier might > screw up some > other component". The answer is simple: behave responsibly, and your > components will not > suffer from this, and therefore, you should not reject a solution because > you will do it > correctly. > **** >> >>You (jumped up on your high horse and) wrote: >> >>"So of course I'll put down someone who doesn't know what they're doing >>and violate fundamental design rules of COM." >> >>and >> >>"So you build bad code, don't be surprised if it fails." > **** > Yep. Bad code fails. And it is part of *my* responsibility to point out > to people who > behave stupidly and irresponsibly that they are behaving stupid and > irresponsibly. > **** >> >>Yet it's pretty common to find a consuming exe coming to grief because >>of incomaptible dlls. This is sometimes refered to as "dll hell". You >>can be the best programmer in the world and still be hit by this. > **** > Incompatible DLLs are a different question than COM interfaces, which is > what I was > talking about. > **** >> >>Now, one mechanism to help prevent this is static linking. There are >>drawbacks, but then everything is a balance. Ease of distribution, and >>the fact that no-one can (accidentally or otherwise) render your exe >>unrunable are advantages in my book. > ***** > Static linking works fine until you are given a DLL or COM component, then > it no longer is > worth talking about. > > Note also that you no longer have the ability to replace components, or > upgrade them, > without a complete relink and redistribution of the entire file, which is > a significant > disadvantage. > **** >> >>You seem to have spent some time quoting COM fundamentals and slinging >>insults without actually addressing the core issue from the original >>post. Namely, can you include a dialog in a static lib (which you can, >>albeit one coded entirely in a function rather than built from a >>resource), and what are the pros and cons thereof. > ***** > I already answered that in a number of ways, including pointing the OP to > at code I wrote > to allow the creation of dialog templates. > ***** >> >>It seems that you aren't very good at accepting alternative opinions. >>There's the Joe-way, and everything else must be the ramblings of an >>idiot. Maybe this is why you keep back the threat to "walk away" from >>"fifth-rate clients". Ultimately, we all have that choice, I suppose. >>But I've found I've got the most out of projects where at first glance >>things were never going to work. But then through compromise and >>innovation (and I admit, a bit of head-banging) things did actually >>work. Threatening to take the ball home is a bit childish, in my opinion. > ***** > There are downsides to several solutions. I pointed out that creating > templates mean that > there is no way to effectively localize the code without introducing > additional > mechanisms. Note that localization has other implications, such as the > fact that in some > languages the labels (static controls) and input (edit controls, combo > boxes) among others > have to be resized to allow for longer words. That won't happen with > hand-crafted code. > > I did not say it was the ramblings of an idiot; I said it was a poor > choice for a variety > of technical and user-oriented reasons. > ***** >> >> >>Joseph M. Newcomer wrote: >>> See below... >>> On Sat, 20 Dec 2008 19:09:14 +0100, Colin Peters <cpeters@coldmail.com> >>> wrote: >>> >>> >>>>Joseph M. Newcomer wrote: >>>> >>>>>The hazards of localization are that you have to create additional >>>>>mechanisms to achieve >>>>>it, such as the file of text. This adds additional complexity to the >>>>>creation, >>>>>management, and distribution of the product. We did a localized >>>>>product in MS-DOS that >>>>>used a separate file. Not an experience I would want to repeat in >>>>>Windows. >>>>> >>>>>Note that for ActiveX, if you believe "the interface changes", then you >>>>>are totally >>>>>clueless about writing ActiveX controls. One of the key rules of >>>>>ActiveX is that the >>>>>interface, once published, NEVER changes, and to violate this rule is a >>>>>deep failure on >>>>>the part of the programmer. Therefore, the interface cannot change. >>>> >>>>Nice try to put down another poster with different opinions to your own, >>>> but you'll have to do more than quote out of context to make any >>>>headway here. >>>> >>>>You might live in a world where the specifications never change and you >>>>implement a perfect solution on day 1. But I don't. Extra methods, >>>>changed parameters, someone "improoving" a dll; these are my daily bread >>>>and butter. In an ideal world once a (COM) interface is registered it >>>>shouldn't change. But it can, and does. Madness, you might say, but it's >>>>still a fact. And when you dynamically link it's out of your hands. >>>>*You* might not be one who changed it, but your exe has to live with the >>>>consequences. Static linkage gives you the peice of mind of knowing that >>>>"when it's in, it's in." >>> >>> ***** >>> Note that I said this specificallyl in reference to ActiveX controls. >>> It is erroneous to >>> modify the interface to an ActiveX control once the design has been set. >>> To change the >>> interface, you create a NEW interface. This is how it works. The >>> third-party companies >>> that have failed to do this have created disasters. So if it changes, >>> it means you have >>> done the wrong thing. Once it is released, it is frozen forever, and it >>> is ALWAYS an >>> error to change it, no exceptions. This is PRECISELY so the problem you >>> mention cannot >>> arise. So don't blame me if you use the mechanisms incorrectly; it >>> isn't my fault if you >>> screw up because you violated design rules. >>> >>> This is why COM interfaces are preferred to raw DLL interfaces if you >>> want stability of >>> the interface. >>> >>> So of course I'll put down someone who doesn't know what they're doing >>> and violate >>> fundamental design rules of COM. These have been established as the >>> Right Way To Build >>> COM Controls, and obviously you missed this critical paragraph in the >>> MSDN (which is upder >>> the caption "Interface Pointers and Interfaces") >>> ========= >>> COM interfaces are immutable--You cannot define a new version of an old >>> interface and give >>> it the same identifier. Adding or removing methods of an interface or >>> changing semantics >>> creates a new interface, not a new version of an old interface. >>> Therefore, a new interface >>> cannot conflict with an old interface. However, objects can support >>> multiple interfaces >>> simultaneously and can expose interfaces that are successive revisions >>> of an interface, >>> with different identifiers. Thus, each interface is a separate contract, >>> and systemwide >>> objects need not be concerned about whether the version of the interface >>> they are calling >>> is the one they expect. The interface ID (IID) defines the interface >>> contract explicitly >>> and uniquely. >>> ========== >>> So why do you say this is "my opinion" when it is stated in the >>> Microsoft documentation as >>> one of the fundamental properties of a COM interface? If you change the >>> methods or add a >>> method, you have violated one of the basic design requirements, and your >>> change is >>> therefore erroneous. So you build bad code, don't be surprised if it >>> fails. Good code >>> cannot fail, because if you update the interface, you create a new >>> interface, and new code >>> uses the new name; as it says above, you can support multiple >>> interfaces. Therefore, >>> there is never a situation in which you have to recompile the client >>> code to use the COM >>> object. It will always work with its registered COM object. Or, the >>> interface changes, >>> and indeed you update the code, because your code needed that new >>> interface, but all the >>> old code continues to run. Or fails because you have removed the >>> interface, but then you >>> know; you don't get access faults or other problems, because either the >>> interface is >>> supported, or it doesn't exist. >>> >>> Sorry to disappoint you, but if you think you are allowed to change the >>> interface specs in >>> COM, you are simply wrong. Go argue with Microsoft. Who will tell you >>> that you are >>> wrong. >>> >>> So you get the interface you want and expect, if you do your job right. >>> If you choose to >>> do it wrong, you suffer the consequences. A properly-done COM control >>> will not have the >>> problems you describe. >>> ****** >>> >>>>I'm not saying always staticly link, but I wouldn't rule out static >>>>linkage just because you have to build dialogs dynamically. Once you've >>>>done a couple it's really quite trivial. >>> >>> ***** >>> I simply don't understand the "single deck of cards was good enough for >>> my >>> great-grandpappy, and by gum it's good enough for me!" attitude. A DLL >>> Is a tool that >>> gives you power and flexibility, and there should be no hesitation to >>> program using modern >>> technology. I feel a bit out-of-place because I *don't* use COM, and >>> probably should; but >>> it is fairly complex and I didn't feel like climbing the curve. But I >>> would have no >>> hesitation in using a DLL. >>> >>> Static linking is occasionally, rarely, useful, and I've used it once or >>> twice, but the >>> basic "I want just one .exe file" attitude seems out of step with modern >>> practice. Why >>> don't we just call all our executables a.exe and be done with it? [In >>> case you don't know, >>> the cc compiler always created an exexcutable called a, unless you used >>> the -o switch to >>> rename the executable file] >>> ***** >>> >>>> >>>> >>>>> joe >>>>>On Thu, 18 Dec 2008 23:04:03 +0100, Colin Peters <cpeters@coldmail.com> >>>>>wrote: >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>Just my 2p worth. Dynamically building dialogs isn't really so tricky. >>>>>>I >>>>>>don't know what problems Joe was alluding to. Dialogs build from >>>>>>resources are anyway build at runtime in a similar way. Look at >>>>>>http://www.codeproject.com/KB/dialog/dynamicdialog.aspx for an >>>>>>example. >>>>>> >>>>>>As far as localisation, you could always access a text file of string >>>>>>translations for the labels, and defautl to a language if no suitable >>>>>>file is found. Quick and dirty at least. The problem with dlls and >>>>>>ActiveX is when your interface changes your exes don't work until you >>>>>>relink. With a static library if it's in it's in. >>>>>> >>>>>>Bill < wrote: >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>I'm trying to create a library of one piece of code so the source can >>>>>>>be >>>>>>>kept secret and only the header and the library file need to be >>>>>>>included in >>>>>>>projects that use it. This is for use within my company. >>>>>>> >>>>>>>The library needs one dialog box to enter some data. I created the >>>>>>>library >>>>>>>and put the dialog inside. I use this library in a project but the >>>>>>>dialog >>>>>>>cannot be created. I get an error -1 from DoModal(). I remember >>>>>>>seeing once >>>>>>>that a project can only have one resource file, so maybe my library >>>>>>>dialog >>>>>>>is not getting included in the final executable. Am I right? Is there >>>>>>>a way >>>>>>>to get it in there? >>>>>>> >>>>>>>I thought I could maybe make this a DLL, but 1. I've never done one >>>>>>>before >>>>>>>and 2. I want to final executable to stand alone without a DLL I must >>>>>>>also >>>>>>>supply. >>>>>>> >>>>>>>I have been trying to InitModalIndirect() from a DLGTEMPLATE but >>>>>>>it's an >>>>>>>uphill battle. I finally got a dialog box to display but the first >>>>>>>button i >>>>>>>tried to add doesn't display. Then i'm wondering how do I link the >>>>>>>button >>>>>>>(or other controls) to the function or variable that I would normally >>>>>>>use >>>>>>>Class Wizard to associate. Does anyone have any exmaple program for >>>>>>>this? >>>>>>> >>>>>>>Thanks, >>>>>>> >>>>>>>Bill >>>>>>> >>>>>>> >>>>> >>>>>Joseph M. Newcomer [MVP] >>>>>email: newcomer@flounder.com >>>>>Web: http://www.flounder.com >>>>>MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer@flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] > email: newcomer@flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
![]() |
0 |
![]() |