Prev: What do you folks use to create icons?
Next: Run time error 4003â?'what can I do ?
From: Karl E. Peterson on 18 Mar 2010 20:26
mp wrote:
> "Karl E. Peterson" <karl(a)exmvps.org> wrote in message
> news:uctDgmuxKHA.404(a)TK2MSFTNGP02.phx.gbl...
>> mp wrote:
>>> "Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
>>> news:eDunKtpxKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>>>> On 18/03/2010 12:52, mp wrote:
>>>>> A million thanks to Ulrich for his awesome cFileSearch class!!!
>>>>>
> snip
>
>>> what about the idea of a separate class to hold the values i want and just
>>> pass that?
>>> pros and cons anyone?
>>
>> I agree. Either pass multiple args, or a class that exposes them as
>> properties. Types really have no place in the COM world.
>
> So any 'best practice' principles to decide between the two?
> multiple args/ vs class ?
>
> Many thanks for your input!
> mark

Probably comes down to personal style, in most cases. For me, there's
a tradeoff of complexity as the number of parameters increases. For
just a few, the class seems like overkill. For many more than that,
it's a blessing. (This is an internal interface, right? No binary
compatibility issues?)

The class method would be a bit more overhead, too, if speed is an
issue.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Ulrich Korndoerfer on 18 Mar 2010 22:06
Hi,

mp schrieb:
> "Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
> news:eDunKtpxKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>> On 18/03/2010 12:52, mp wrote:
>>> A million thanks to Ulrich for his awesome cFileSearch class!!!
>>>
>>>
>>> so i wanted to pass the whole udt in an event instead of just the
>>> filename
>>> Event FirstFileNewerUDT(Firstname As String, INFO As TFileData)
>>> !!!-can't do that - "Only public types in public objects can be used as
>>> arg
>>> etc etc - error msg"
>>>
>>> So i guess i'll just create a new little class to hold the elements and
>>> pass
>>> the object instead of the udt???
>>> or create the event to pass multiple args instead of just one object?
>> Can't you move the type into the class file?
>>
>> I can never remember the limitations on classes and types until I come
>> accross them.
>>
>> --
>> Dee Earley (dee.earley(a)icode.co.uk)
>
> I will try that. so I just copy the Public def from the bas into the cls?
> Then i wonder if i have to copy it into the form as well, in order to
> receive it in the event?
> I'll play around with that...
> I was thinking that one only wants a definition in one place, and since the
> CFileSearch Class needs it in mFileSearch.Bas, that making copies was not a
> good idea....but if it works what the heck.
>

Yes, definitions in principle should be kept in the same place that uses
them.

But CFileSearch as downloaded from my web site is intended to be used by
embedding its source into a normal exe. For this use case the UDT
definitions must be (and therefore are) declared public in a module (and
the class properties using them must have scope Friend).

This is a workaround around a VB bug. Normally one would declare the
type (UDT) in the class itself with public scope. But VB does not allow
this (which I consider to be a bug), when the class is embedded in a
standard exe.

However this workaround (declaring the UDT in a module and scoping all
methods of the class that use them as Friend) does not work for events.

So one solution for your problem would be to put the class into a dll
project. Then copy the declarations from the module over into the class,
and alter the scope of all Friend methods in the class to Public. The
module then is no longer needed and events then work with UDTs.

> what about the idea of a separate class to hold the values i want and just
> pass that?
> pros and cons anyone?

It depends from where the event is raised. If you have extended my class
by adding your events to CFileSearch, and raise them from there, then,
after putting the class into a dll, the fastest method would be to hand
over the TFileData UDT ByRef in your event.

Declaration in CFileSearch would be e.g.:

Event MyEvent(ByRef INFO As TFileData)

and raise it such:

RaiseEvent MyEvent mDirs(DirIdx).FoundFiles(FileIDx)

where mDirs is the member of CFileSearch holding the data.

However if you raise your event in an other class than CFileSearch,
other possibilities are there which would allow to still embed
CFileSearch in a standard exe.

Eg if you have written a wrapper class, that uses CFileSearch, and want
to raise events from there, just simply declare your event in your
wrapper class as

Event MyEvent(ByVal FileSearch As CFileSearch, _
ByVal DirIdx As Long, _
ByVal FileIdx As Long)

To transport the data, yo do not need to create a separate data
container class, because you already have one: CFileSearch itself.

To my sadness I must admit, that I forgot to implement (in CFileSearch)
properties to get access to one TFileData item or to a member of one
TFileData item. As a remedy copy following into CFileSearch:

Friend Property Get Dirs_FoundFile(ByVal DirIdx As Long, _
ByVal FileIdx As Long) _
As TFileData
Dirs_FoundFile = mDirs(DirIdx).FoundFiles(FileIdx)
End Property

Friend Property Get DirsTree_FoundFile(ByVal DirTreeIdx As Long, _
ByVal FileIdx As Long) _
As TFileData
DirsTree_FoundFile = _
mDirs(mDirsTreeIdxs(DirTreeIdx)).FoundFiles(FileIdx)
End Property

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
From: Dee Earley on 19 Mar 2010 05:05
On 19/03/2010 02:06, Ulrich Korndoerfer wrote:
>> "Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
>> news:eDunKtpxKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>>> Can't you move the type into the class file?
>>>
>>> I can never remember the limitations on classes and types until I
>>> come accross them.
>
> This is a workaround around a VB bug. Normally one would declare the
> type (UDT) in the class itself with public scope. But VB does not allow
> this (which I consider to be a bug), when the class is embedded in a
> standard exe.

Ahh yes, that was it.
My stupid memory is going... :)

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems
From: Dee Earley on 19 Mar 2010 05:07
On 18/03/2010 18:09, mp wrote:
> "Nobody"<nobody(a)nobody.com> wrote in message
> news:eJ4ZterxKHA.2012(a)TK2MSFTNGP04.phx.gbl...
>> "mp"<nospam(a)thanks.com> wrote in message
>> news:uyUbzXrxKHA.2432(a)TK2MSFTNGP04.phx.gbl...
>>> I sent this at 8 am but it never showed up, i wonder if replying will show
>>> up?
>>
>> It showed up for me using ms news server. There are 2 replies by Dee
>> Earley.
>>
>> news://msnews.microsoft.com/microsoft.public.vb.general.discussion
>
> Interesting! I didn't know about this server...i've always linked to
> news.microsoft.com
> are these basically duplicate server names?

They are the same server:
> Non-authoritative answer:
> Name: msnews.microsoft.com
> Address: 207.46.248.16
> Aliases: news.microsoft.com

> but yes, it does show up here and not on news.microsoft.com for me in
> outlookexpress anyway

Adding the other server caused it to refetch all the message headers,
including the "lost" message.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems
From: mp on 19 Mar 2010 08:29
Thank you for your response.
"Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> wrote in message
news:%23NzRdjwxKHA.5776(a)TK2MSFTNGP06.phx.gbl...
> Hi,
>
> mp schrieb:
>> "Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
>> news:eDunKtpxKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>>> On 18/03/2010 12:52, mp wrote:
>>>> A million thanks to Ulrich for his awesome cFileSearch class!!!
snip

> Yes, definitions in principle should be kept in the same place that uses
> them.

Thanks, that's what i was thinking

> But CFileSearch as downloaded from my web site is intended to be used by
> embedding its source into a normal exe. For this use case the UDT
> definitions must be (and therefore are) declared public in a module (and
> the class properties using them must have scope Friend).
>
> This is a workaround around a VB bug. Normally one would declare the type
> (UDT) in the class itself with public scope. But VB does not allow this
> (which I consider to be a bug), when the class is embedded in a standard
> exe.
>
> However this workaround (declaring the UDT in a module and scoping all
> methods of the class that use them as Friend) does not work for events.
>
> So one solution for your problem would be to put the class into a dll
> project. Then copy the declarations from the module over into the class,
> and alter the scope of all Friend methods in the class to Public. The
> module then is no longer needed and events then work with UDTs.

Thanks for that pointer, due to my limited programming chops i'd rather keep
it simple and use the class as is, rather than adding a dll layer to my
mental confusion :-)

>> what about the idea of a separate class to hold the values i want and
>> just pass that?
>> pros and cons anyone?
>
> It depends from where the event is raised. If you have extended my class
> by adding your events to CFileSearch, and raise them from there, then,
> after putting the class into a dll, the fastest method would be to hand
> over the TFileData UDT ByRef in your event.
>
> Declaration in CFileSearch would be e.g.:
>
> Event MyEvent(ByRef INFO As TFileData)
>
> and raise it such:
>
> RaiseEvent MyEvent mDirs(DirIdx).FoundFiles(FileIDx)
>
> where mDirs is the member of CFileSearch holding the data.


> However if you raise your event in an other class than CFileSearch, other
> possibilities are there which would allow to still embed CFileSearch in a
> standard exe.

yes, this is my situation

> Eg if you have written a wrapper class, that uses CFileSearch, and want to
> raise events from there, just simply declare your event in your wrapper
> class as
>
> Event MyEvent(ByVal FileSearch As CFileSearch, _
> ByVal DirIdx As Long, _
> ByVal FileIdx As Long)
>
> To transport the data, yo do not need to create a separate data container
> class, because you already have one: CFileSearch itself.

i'll have to think about that, by the time i raise the event cFileSearch has
long ago done it's work, and now i'm just comparing the filenames, and dates
from one drive to the other.... I'll have to go back and see if at that
point i'd still have a reference to the indexes that originally pulled the
file info out of cfilesearch.


> To my sadness I must admit, that I forgot to implement (in CFileSearch)
> properties to get access to one TFileData item or to a member of one
> TFileData item. As a remedy copy following into CFileSearch:
>
> Friend Property Get Dirs_FoundFile(ByVal DirIdx As Long, _
> ByVal FileIdx As Long) _
> As TFileData
> Dirs_FoundFile = mDirs(DirIdx).FoundFiles(FileIdx)
> End Property
>
> Friend Property Get DirsTree_FoundFile(ByVal DirTreeIdx As Long, _
> ByVal FileIdx As Long) _
> As TFileData
> DirsTree_FoundFile = _
> mDirs(mDirsTreeIdxs(DirTreeIdx)).FoundFiles(FileIdx)
> End Property
>
> --
> Ulrich Korndoerfer

awesome! Thanks for the additions...I'll plug them in and see if i can make
use of them - now or in the future!
Thanks again for a generous wonderful source code
mark


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: What do you folks use to create icons?
Next: Run time error 4003â?'what can I do ?