From: MikeD on 26 Mar 2010 12:49 "sven2000" <sven2000(a)gmail.com> wrote in message news:eee0802d-8804-403b-9148-7f703d8b8b81(a)g10g2000yqh.googlegroups.com... > I'm trying to lock out a part of the code depending on a status flag. > However VB insists that it still needs the procedure that I've ocked > out. Is there a way to make this work? > > StandAlone = True > > If StandAlone Then > Call LineXX(0, 0, 100, 100) > Else > Call LineAA(0, 0, 100, 100) > End If Not exactly sure what you mean by locked out. I'm guessing you want to remove one or the other of those procedures. You'll have to comment out (or remove) the corresponding call to it as well. Or, as suggested, you can use conditional compilation. Or, just leave both the procedure and the call alone. What's it hurting? -- Mike
From: sven2000 on 26 Mar 2010 13:11 *************************************************************** SOLVED (with conditional compilation) *************************************************************** On Mar 26, 6:41 pm, "Larry Serflaten" <serfla...(a)usinternet.com> wrote: > If its one set of routines, vs another similarly named set, you might > be able to use COM. One class has one set, a different class has > another, and you instantiate the class you need when the flag is set. I'm not advanced enough as a programmer that I'm using those. On Mar 26, 5:49 pm, "MikeD" <nob...(a)nowhere.edu> wrote: > Not exactly sure what you mean by locked out. I'm guessing you want to > remove one or the other of those procedures. You'll have to comment out (or > remove) the corresponding call to it as well. Or, as suggested, you can use > conditional compilation. Or, just leave both the procedure and the call > alone. What's it hurting? Commenting out is possible, but inconvenient to do. By creating stand alone units I can prove to myself that I'm not writing spaghetti. I think it has other benefits as well.
From: Horst Heinrich Dittgens on 26 Mar 2010 13:40 The compiler will always ask for both routines if coded in this manner, it doesn't know that LineAA never will be called. I think there might be a way using COM and late binding where the existence of LineAA is not checked at compile time but at run time, so if you never call LineAA the code of LineAA doesn't need to exist. There might be experts here who can line out this way better than I ever can do. If you simply don't want to add a large code fragment containing Sub LineAA you could simply add an empty Sub LineAA()..End Sub block.
From: MikeD on 26 Mar 2010 18:58 "sven2000" <sven2000(a)gmail.com> wrote in message news:60bc06f7-40f3-40e3-a3b8-6e396cf86ea6(a)h18g2000yqo.googlegroups.com... > > By creating stand > alone > units I can prove to myself that I'm not writing spaghetti. I think it > has > other benefits as well. Not really sure what you mean by that either. Having a procedure in your project that you never call is not spaghetti code. I guess much of what your saying is unclear because you haven't described the "big picture". Oh well. As long as you got it sorted out. -- Mike
From: sven2000 on 26 Mar 2010 19:24 On Mar 26, 11:58 pm, "MikeD" <nob...(a)nowhere.edu> wrote: > Not really sure what you mean by that either. Having a procedure in your > project that you never call is not spaghetti code. I guess much of what your > saying is unclear because you haven't described the "big picture". Oh well. > As long as you got it sorted out. I'm not a programmer so I'm still stuck building programs the way I've learned when learning turbo pascal 15 or 20 years go. However, I do program and I've found that as programs get bigger, modules slowly start to blend together. I've noticed that some of my older programs don't work anymore and that they are hard to fix because of that. My idea was to disable or take out modules and still have the program to work. For example I can take out the antialias module if a dll doesn't work properly on a new system, but still get usefull output (albeit not pretty rendered).
First
|
Prev
|
Pages: 1 2 Prev: Create ItemCheck event with Listview from Common Controls 5.0 Next: Improving Error Routine |