ActiveX EXE Books etc?
in [Visual Basic]
|
Prev: Fast way to delete files
Next: 'MappingInfo
From: Schmidt on 25 Oct 2009 19:26 "Bee" <Bee(a)discussions.microsoft.com> schrieb im Newsbeitrag news:355E1FA6-D1F4-44BB-BC8D-5041AB3DF16C(a)microsoft.com... > I follow what you wrote. > I see how I can pass initial parameters when the class is > instantiated. Yes of course, by adding them to the AddThread-method... > But I do not understand how to do this type of interface > after using the suggested collection. The used Collection inside the Factory is just there, to keep the references to cEvtWrapper (which in turn indirectly host the ThreadInstances) alive. To make the Thread-Interface "visible" over a Factory- method (or property), you will need to expose the ThreadInstance, from inside cEvtWrapper first ... To achieve this, it is enough, to change: Private WithEvents oAxExeThread As cAxExeThread to Public WithEvents oAxExeThread As cAxExeThread inside cEvtWrapper. And since the different (threadcount = n) EvtWrappers are finally all hosted in Col (the Collection within cFactory), which is already public, you could now already access your Thread-Objects over: oFactory.Col(1 - n).oAxExeThread That is probably not yet nice enough, since it works latebound, so instead you could also hide the Collection again inside cFactory and make it Private - and now implement an additional Item-Property in cFactory: Public Property Get Item(IndexOrKey) As cAxExeThread Set Item = Col(ItemOrKey).oAxExeThread End Property That's it IMO (you can now access a ThreadInstance over oFactory.Item(...) in an earlybound fashion). Now, if you wonder why I've named the Item-Prop- Parameter IndexOrKey ... why not include an additional KeyString-Identifier as one of the passed Parameters in your oFactory.AddThread-Method...: oFactory.AddThread(ThreadKey$, OtherInitParams,...) 'inside the Add-method now just ensure, that 'the Col.Add method respects also the above passed 'ThreadKey$-Param in its second parameter. If you want to be lazy, and not type the full: oFactory.Item(Index) or oFactory.Item(Key) you could also set the Default-Flag (over the extended procedure-settings) for your Item-Prop. That would allow an array-like access, directly on oFactory then: oFactory(Index).SomeThreadProperty = ... or oFactory(Key).SomeThreadProperty = ... Now your turn again...;-) Olaf
From: mayayana on 25 Oct 2009 21:47 You may see something I missed, but is there any reason that the complexity you're suggesting is necessary and the simpler method I posted can't be used? I only wrote it as "air code", but it seems to work fine. > > I follow what you wrote. > > I see how I can pass initial parameters when the class is > > instantiated. > > Yes of course, by adding them to the AddThread-method... > > > But I do not understand how to do this type of interface > > after using the suggested collection. > The used Collection inside the Factory is just there, to > keep the references to cEvtWrapper (which in turn > indirectly host the ThreadInstances) alive. > > To make the Thread-Interface "visible" over a Factory- > method (or property), you will need to expose the > ThreadInstance, from inside cEvtWrapper first ... > To achieve this, it is enough, to change: > Private WithEvents oAxExeThread As cAxExeThread > to > Public WithEvents oAxExeThread As cAxExeThread > inside cEvtWrapper. > > And since the different (threadcount = n) EvtWrappers > are finally all hosted in Col (the Collection within cFactory), > which is already public, you could now already > access your Thread-Objects over: > oFactory.Col(1 - n).oAxExeThread > > That is probably not yet nice enough, since it works latebound, > so instead you could also hide the Collection again inside > cFactory and make it Private - and now implement an > additional Item-Property in cFactory: > > Public Property Get Item(IndexOrKey) As cAxExeThread > Set Item = Col(ItemOrKey).oAxExeThread > End Property > > That's it IMO (you can now access a ThreadInstance > over oFactory.Item(...) in an earlybound fashion). > > Now, if you wonder why I've named the Item-Prop- > Parameter IndexOrKey ... why not include an additional > KeyString-Identifier as one of the passed Parameters in > your oFactory.AddThread-Method...: > > oFactory.AddThread(ThreadKey$, OtherInitParams,...) > 'inside the Add-method now just ensure, that > 'the Col.Add method respects also the above passed > 'ThreadKey$-Param in its second parameter. > > If you want to be lazy, and not type the full: > oFactory.Item(Index) > or > oFactory.Item(Key) > you could also set the Default-Flag (over the > extended procedure-settings) for your Item-Prop. > > That would allow an array-like access, directly on > oFactory then: > oFactory(Index).SomeThreadProperty = ... > or > oFactory(Key).SomeThreadProperty = ... > > Now your turn again...;-) > > Olaf > >
From: Schmidt on 25 Oct 2009 23:14 "mayayana" <mayaXXyana(a)rcXXn.com> schrieb im Newsbeitrag news:%23XM6qWdVKHA.844(a)TK2MSFTNGP05.phx.gbl... > You may see something I missed, but is there > any reason that the complexity you're suggesting > is necessary and the simpler method I posted > can't be used? I only wrote it as "air code", but > it seems to work fine. Your code should work fine too of course - I would (presumably) have written it exactly this way, if I wanted to implement a "fast solution with an expected lifetime that is not all that large". But you probably know yourself, how such seemingly "throw-away-projects" grow sometimes - they just don't want to die... ;-) Your class C1 does basically the same as cEvtWrapper. You will need such a small (indirect) Event-Receiver-class in either case, to be able to aggregate Events of other Objects somehow - so, not much difference here. The only thing which is basically different between our approaches is, that you spare out the cFactory, and let the Form-Class do its work instead (directly). But that in turn requires your C1-Class, to *know* the concrete Class-Interface of your Form (Form1) ... Now, if you want to use your C1 implementation also in other Forms (i.e Form2 or Form3), then you would have to rewrite or adapt your C1-EventDelegation-code. In my opinion the additional cFactory leads to a cleaner implementation, since you could (re)use such a Factory in any Form- or Class-module, not only in an "especially adapted Form1". Also, cEvtWrapper, as well as cFactory could be moved outside of the Main-project (into an ActiveX-Dll) without problems (in case you'd want to go there - i.e. if your project-code grows - and the factory- construct + some additions here an there became proven and stable over time). Aside from that, Bee asked directly for explanations of the "factory-term" or "factory-patterns" others have brought up. I just tried to fill that pattern with some life, focussing a bit on his concrete scenario. Introducing a Form as the final "factory-endpoint" where everything is glued together in the end, just didn't seem right to me in this "please explain a factory"-context. A dedicated class with an appropriate name, encapsulating the details "away" and thereby able to disburden the Form- (GUI)Code to some extend, seemed more reasonable to me. Also in your example the "constructor-effect" of a dedicated factory is not addressed ... i.e. you need this codelines: Set a1(0) = New C1 a1(0).ID1 = 0 a1(0).StartTime 2000 Set a1(1) = New C1 a1(1).ID1 = 1 a1(1).StartTime 5000 ....where with a fully implemented cFactory you could write: oFactory.AddThread 0, 2000 oFactory.AddThread 1, 5000 Just my 2 cents, hope no offense is taken...;-) Olaf
From: mayayana on 26 Oct 2009 00:55 > > Just my 2 cents, hope no offense is taken...;-) > Not at all. You know more about this than I do, so I was interested in your assessment.
From: Dee Earley on 26 Oct 2009 05:32
On 23/10/2009 19:20, mayayana wrote: >> why? well because that is how i first learned to access this newsgtroup. >> I have Windows Live Mail that has newsreader. > > I've never used Windows Mail. Is that the same as > Windows Live Mail? I thought it was just Vista's > renamed Outlook Express. Windows Mail was Outlook express under a new name. Windows Live Mail is a slightly enhanced version. -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems |