It's always intrigued me, why didn't MS make the classic VB Tag property a variant?

[MM]

At least from Visual Basic 5 onwards?

I've started using the Tag property to store a "key" which I use in
conjunction with the Dictionary object. So much better than using an
array to store extra data, but even better would be the ability to
store more than one item of data directly in the Tag property.

Oh, I know programmers have indeed stored multiple values in the Tag
property. I myself once wrote several routines to separate the values
using the pipe character. But it's not as clean a solution as having
an array in a variant that one can whack straight into the Tag
property in the first place.

If MS had changed the Tag variable type to a Variant in later
versions, it wouldn't have broken earlier code that was being
upgraded.

MM

[Deanna Earley]

While it's source compatible, it wouldn't be COM compatible.
While this shouldn't be a huge problem normally, if any of those
controls are exposed as a COM interface, then the library's entire
typelib will be changed.

--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[ralph]

Well actually the Tag Property is a Variant*, but it is restricted to
"values" (cannot hold references or objects) because there is no
additional storage associated with it.

You can provide additional storage (and properties) by sub-classing or
wrapping a Control with your own User Control. However, usually by the
time you wrap a control - other strategies become more useful.

The Tag Property itself was designed and provided for a very limited
propose - a simple mechanism to provide a 'unique' identifier for a
particular control. The fact that any identifier can be 'abused' to
supply meta data is a handy tool. For example, we can have an element
that is simply "Tony Romo", or we can provide "Tony
Romo|quarterback|Dallas|Cowboys|Accident waiting to happen", but
trying to 'tag' something as an OverPaidQuarterback object is a
redirection too far. <bg>

-ralph
[* The Tag Property of Control which most VB controls derive from.
There are other Tag Properties out there that are more severally
typed. The 'default' type is string, and the helpstring attribute
defines it as a string, and within VB sematics and ETC you'll find it
easier to just treat it as a string and avoid surprises. <g>]

[Deanna Earley]

On 13/05/2013 15:48, ralph wrote:
> Well actually the Tag Property is a Variant*, but it is restricted to
> "values" (cannot hold references or objects) because there is no
> additional storage associated with it.

Do you have a reference for that?
All the intrinsic controls I can see in the VB6 object viewer have:
Property Tag As String

[ObiWan]

> I've started using the Tag property to store a "key" which I use in
> conjunction with the Dictionary object. So much better than using an
> array to store extra data, but even better would be the ability to
> store more than one item of data directly in the Tag property.

well... why don't you use the tag value (you set it) as a key to a
propertybag entry ? That way you'll be able to read/write "attached
stuff" on the fly which, in turn, may be useful to save state or do a
whole bunch of stuff (including storing extra volatile stuff in some
dictionary while keeping the dict key into an entry of the property bag)

[ralph]

On Mon, 13 May 2013 15:58:44 +0100, Deanna Earley
<dee.e...@icode.co.uk> wrote:

>On 13/05/2013 15:48, ralph wrote:
>> Well actually the Tag Property is a Variant*, but it is restricted to
>> "values" (cannot hold references or objects) because there is no
>> additional storage associated with it.
>
>Do you have a reference for that?
>All the intrinsic controls I can see in the VB6 object viewer have:
>Property Tag As String

It gets that from the helpstring attribute, not the actual signature
of the coclass (which is pure binary).

You will find the same phenomena with other properties as well, eg
.Text. They are in fact all variants. It is one of the interesting OO
aspects of VB (and OLE) allowing polymorphic parameter passing without
getting mismatch type violations.

But I should have never gone there. It servers little useful purpose
for VBers. Merely a case of me being a know-it-all (or worse, a
smart-a** <g>).

[So what should I have said, if I wanted to point out why one is
limited to "values" and why objects are not allowed? To simply say
there is no "storage" is less than adequate since then one has to go
on to explain base-type local marshaling and/or lack of. Then the more
I chewed on it, I began to appreciate there was more method than
madness in how the VB pcode parser was handling the parameter passing.
ie, we end up with a Variant with an asterisk. Wow. that is sure
helpful. <g>]

So, I'll back up. You're absolutely correct. The Tag Property is a
String. Going anywhere else serves no useful purpose.

-ralph

[Jim Mack]

On 5/13/2013 12:46 PM, ralph wrote:

>>> Well actually the Tag Property is a Variant*, but it is restricted to
>>> "values" (cannot hold references or objects) because there is no
>>> additional storage associated with it.
>>
>

> It gets that from the helpstring attribute, not the actual signature
> of the coclass (which is pure binary).

I've written a number of typelibs but I'm no way an expert. However, I
do know that you can't influence what VB reports as the Type by changing
the Helpstring. The reported type _is_ the type, as far as this
interface knows.

It may be picking nits, but if a Variant cannot contain all the types
that an OLE VARIANTDEF allows, how is it then a Variant? And how does
one go about restricting the types that it can contain, using ODL/IDL?

It seems more a case of ETC. A String can 'contain' any scalar type, in
a sense, because of ETC, but it is always a string. So if it acts like a
string, and says it's a string, what do we gain by thinking of it as
anything else? Are there properties of these... properties that make
their secret life as variants known in any way, or that we can exploit?

--
Jim

[ralph]

On Mon, 13 May 2013 13:53:36 -0400, Jim Mack <no-ub...@mdxi.com>
wrote:

I agree a hundred percent.

-ralph

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribió en el mensaje
news:20130513173...@deathstar.mil...

It the issue is to store values just at run time, he could use a global
collection.

GTag (Text1) = whatever

' In a module
Public gTags as New Collection

Public Property Let GTag (nControl as Object, nValue as Variant)
gTags(ControlNameWithParent(nControl)) = nValue
End Property

Public Property Get GTag (nControl as Object) as Variant
GTag = gTags(ControlNameWithParent(nControl))
End Property

Public Function ControlNameWithParent(nControl As Object) As String
Dim iContainer As Object
Dim iAuxStr As String

On Error GoTo TheExit:

If nControl Is Nothing Then
ControlNameWithParent = ""
Else
iAuxStr = nControl.Name
Set iContainer = nControl.Container
Do Until iContainer Is nControl.Parent
iAuxStr = iContainer.Name & "." & iAuxStr
Set iContainer = iContainer.Container
Loop
iAuxStr = nControl.Parent.Name & "." & iAuxStr
ControlNameWithParent = iAuxStr
End If

Exit Function

TheExit:
On Error GoTo -1
On Error Resume Next
ControlNameWithParent = nControl.Name
End Function

[MM]

On Mon, 13 May 2013 16:08:48 -0300, "Eduardo" <m...@mm.com> wrote:

>
>"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje

Aarrrrggghhh! Please, NO Collection! The Dictionary object is streets
ahead in terms of functionality. It works brilliantly the way I am
using it for storing extra data about the control array elements I am
manipulating at run time. I store the Dictionary key in the Tag
property and a UDT ( based on a class) in the Dictionary's item. For
unique keys I'm using GetTickCount.

Mind you, I only have a small number of elements in my control array
(new elements are loaded, or existing ones unloaded, at runtime), so
this approach, using the Dictionary object, might be less suitable if
one had dozens of control array elements.

You see, I had initially tried using a UDT array, but the problem with
arrays arises when you need to delete an element. When I unload (at
runtime) the associated *control array* element, it's gone for ever
and the existing elements retain their Index values. But when I then
"remove" the associated UDT array element, well, what then? Set a
value to Null or -1 to indicate it's dead? Sure, I could use Redim
Preserve if it happened to be the last element, but what if I'm
removing element 4 from an array of 8 elements? Or I could make it
even more complex using a linked list or something.

All this palaver is avoided by using the Dictionary object instead.

When I remove (unload) one of the control array elements, first noting
its Tag value, and then remove the associated Dictionary key/item
entry, it is also gone forever. As I add or remove control array
elements, I can do exactly the same with the parallel Dictionary so
that the two entities are completely in sync with each other, tied
through their keys via the Tag property.

By the way (to Ralph now...) I received that book you recommended and
it is indeed very well laid out and full of very precise yet
comprehensible details about COM and ActiveX controls. An excellent
read, and I can't believe it only cost me a penny, plus postage. And
the Marketplace retailer was on the ball, too, because I received the
book the day after Amazon informed me that it had been despatched!
Counting the total value of the stamps he put on he could only have
made a few pennies profit.

MM

[Eduardo]

"MM" <kyli...@yahoo.co.uk> escribi� en el mensaje
news:nuk3p8lkb8k3sbug1...@4ax.com...

Then just use ControlNameWithParent (Control) as your key for the
dictionary.

> Mind you, I only have a small number of elements in my control array
> (new elements are loaded, or existing ones unloaded, at runtime), so
> this approach, using the Dictionary object, might be less suitable if
> one had dozens of control array elements.

I see that I don't handle controls arrays in that function
(ControlNameWithParent), but that can be easily added.

> You see, I had initially tried using a UDT array, but the problem with
> arrays arises when you need to delete an element. When I unload (at
> runtime) the associated *control array* element, it's gone for ever
> and the existing elements retain their Index values. But when I then
> "remove" the associated UDT array element, well, what then? Set a
> value to Null or -1 to indicate it's dead? Sure, I could use Redim
> Preserve if it happened to be the last element, but what if I'm
> removing element 4 from an array of 8 elements? Or I could make it
> even more complex using a linked list or something.

What About using ObjPtr (Control) as the key?

[Eduardo]

"Eduardo" <m...@mm.com> escribi� en el mensaje
news:kmsnum$f6f$1...@speranza.aioe.org...

> I see that I don't handle controls arrays in that function
> (ControlNameWithParent), but that can be easily added.

Public Function ControlNameWithParent(nControl As Object) As String
Dim iContainer As Object
Dim iAuxStr As String

Dim iAuxStr2 As String

On Error GoTo TheExit:
If nControl Is Nothing Then
ControlNameWithParent = ""
Else
iAuxStr = nControl.Name

On Error Resume Next
iAuxStr = iAuxStr & "_" & nControl.Index
On Error GoTo TheExit:

Set iContainer = nControl.Container
Do Until iContainer Is nControl.Parent

iAuxStr2 = iContainer.Name
On Error Resume Next
iAuxStr2 = iAuxStr2 & "_" & iContainer.Index
On Error GoTo TheExit:
iAuxStr = iAuxStr2 & "." & iAuxStr

Set iContainer = iContainer.Container
Loop
iAuxStr = nControl.Parent.Name & "." & iAuxStr
ControlNameWithParent = iAuxStr
End If

Exit Function

TheExit:
On Error GoTo -1
On Error Resume Next

ControlNameWithParent = nControl.Parent.Name
ControlNameWithParent = ControlNameWithParent & nControl.Name
ControlNameWithParent = ControlNameWithParent & "_" & nControl.Index
End Function

[MM]

I don't think you're quite following my drift here.

What I have is a control array with a single element, elment 0, placed
on a picture box at design time. At runtime I can create (load) or
remove (unload) certain elements depending on requirements.

Each control array element has its intrinisc properties like
ForeColor, Visible. But I need extra properties. I need to record
where the control array element is on the form or picture box. I also
need to record other data, let's say for example, whether it
represents a Piano, Violin or Trumpet.

So the question arises, where does one store that extra data, those
extra "properties"? Obviously, from a purist's POV the ideal solution
is a user-defined control, but I'm not up to speed (yet!) on them.

My first attempt therefore used a UDT array, something like:

Type MyType
MIDINumber As Integer
Instrument as Integer ' 1 = Piano; 2 = Violin; 3 = Trumpet
End Type

Each time I loaded a new control array element I created a new element
in the UDT array and stored the extra data. Fine. That works okay.

But the difficulties start when I want to unload a control array
element. Let's say, the violin player's G string snapped and she's
left the building. I have 8 elements in the control array, element 0
being the one placed on the form at design time and not itself used
for anything. So 7 actual, usable elements.

Now I remove (unload) one of the elements, say element 6. Now the
control array actually contains only 7 elements! The one I removed has
gone completely. There's no trace of it, just like the absent violin
player.

Then I turn to the UDT array and the head scratching begins. How do I
remove *its* element 6 so that there are only 7 elements? Well, of
course, it's ~possible~ by copying to a temporary array, then using
Redim Preserve, copying back and so on and so forth. But it's messy
beyond belief. Only if I was lucky that the element to be removed was
the topmost one, element 8, could I have used Redim Preserve directly
without too much hassle.

So then along comes the Dictionary object (I've used it off and on for
ten years at least) and lo! There is the simple solution, short of a
user control. Each time I load a new control array element, I create a
new entry in the Dictionary. I can address any entry by means of the
Key property. So I think to myself, how many elements can you create
interactively in a second, and the answer is "not many", therefore
GetTickCount provides adequate uniqueness for my purpose. So I store
the new entry in the dictionary with its key value set to GetTickCount
and I place that value in the Tag property of the control array
element. The control array element is thus explicitly associated with
the Dictionary entry.

So, whenever I need to unload a control array element, I first remove
the Dictionary entry (keyed via the element's Tag property), then I
complete the actual unloading. Result: Both the control array and the
Dictionary stay absolutely in sync. No messy/complex linked list,
Redim Preserve, array compacting etc etc. The Dictionary (modelled on
a Perl associative array) does everything I need.

MM

[Eduardo]

"MM" <kyli...@yahoo.co.uk> escribi� en el mensaje

news:if64p8psn8ubn2l9r...@4ax.com...

[...]

I see that you have all resolved. I thought that you still needed a
solution.

Two options to explore:

To use ObjPtr instead of the GetTickCount number stored in the Tag property.
To use a class instead of an UDT.

But if you have the code working, why to change?

[Mayayana]

| Aarrrrggghhh! Please, NO Collection! The Dictionary object is streets
| ahead in terms of functionality.

And the editor of VB and VBA in a Nutshell says
it's also quite a bit faster. But Dictionary is actually
part of the Windows Script Host package. It comes
from scrrun.dll. As with FileSystemObject, you're
bringing in an unnecessary dependency. It may be
fairly safe to use these days, since WSH comes pre-
installed as system files that are locked, but in the
past many corporate admins have removed those files
for security reasons. ...Something to be aware of if
you distribute your software.

[MM]

I was only asking *why* MS never thought of changing the Tag property
to Variant type, in which one could have stored an array of values,
not a single value.

I *am* now using a class! I have to, because if one tries to use a UDT
in conjunction with the Dictionary object the dreaded "Only
user-defined types defined in public object modules can be coerced to
or from a variant or passed to late-bound modules." error. By using a
class with exactly the same members as the UDT, this error does not
occur and it all works brilliantly.

So, just to be clear, instead of

Type NoteDataType
MIDINumber as Integer
MouseX as Single
MouseY as Single
Key as Variant
DisplacedFlag as Boolean
End Type

I created clsNoteData:

Public MIDINumber as Integer
Public MouseX as Single
Public MouseY as Single
Public Key as Variant
Public DisplacedFlag as Boolean

That's all the class contains. Nothing else.

So when I need to retrieve some data from an entry in the Dictionary,
I can do e.g.

Dim test as New clsNoteData
Dim Key as Variant

Key = Xyz(Index).Tag ' Where Xyz is the control array

Set test = NotesDict.Item(Key)

Debug.Print test.DisplacedFlag

I've since found a shortcut that works, too:
Debug.Print NotesDict.Item(Key).DisplacedFlag

MM

[ObiWan]

> > well... why don't you use the tag value (you set it) as a key to a
> > propertybag entry ? That way you'll be able to read/write "attached
> > stuff" on the fly which, in turn, may be useful to save state or do
> > a whole bunch of stuff (including storing extra volatile stuff in
> > some dictionary while keeping the dict key into an entry of the
> > property bag)

> It the issue is to store values just at run time, he could use a
> global collection.

set aside the fact that I'd prefer a dictionary over a collection (not
to name other objects which you may "cast" over the data); my humble
suggestion was just some kind of addition to what others suggested and
only in the spite of suggesting the OP a quick way to not only store
data linked to the "tag" but to also be able to persist/reload them
with ease

[MM]

From XP onwards, the OS appears to contain all the standard supporting
files, like the VB runtime, which I no longer issue and have never had
a problem with backward compatibility. And corporate admins are
unlikely to be much interested in my MIDI software anyway!

I'm not entirely happy with the "quick solution" you say some admins
have adopted. What if one of their own programmers needed to use some
component the admins had simply removed? It's sounds like using a
hammer to crack a nut. There must be more sophisticated ways to ensure
system security/integrity instead of fiddling with locked system
files. Some admins may know what they're doing, but in my previous
experience, others barely know how to boot up a PC.

MM

[Eduardo]

"MM" <kyli...@yahoo.co.uk> escribió en el mensaje
news:v2f4p8dna8593uov4...@4ax.com...

> I was only asking *why* MS never thought of changing the Tag property
> to Variant type, in which one could have stored an array of values,
> not a single value.

Yes, that would had been useful if they had done.

[Eduardo]

"MM" <kyli...@yahoo.co.uk> escribi� en el mensaje
news:8tf4p8t7qr40n7vj2...@4ax.com...

But is there any problem with using collections?

I don't see in which way that dictionary is better than a collection in your
specific case.

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje
news:20130514155...@deathstar.mil...

Where do you save the PropertyBag from one run to another?

[ObiWan]

> > not only store data linked to the "tag" but to also be able to
> > persist/reload them with ease

> Where do you save the PropertyBag from one run to another?

I suppose you used PBs, didn't you ? If so, you should exactly know the
"save" options you have (and those even include alternate data streams
if you really want to go that deep)

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje

news:20130514163...@deathstar.mil...

I only used them in UserControls for design time data storage, and it's
handled automatically by VB.

[Phil Hunt]

Yes, that's the way to go. UDT is nice to keep relevent data together, but
it is not portable, eg passing/returning to fucntion.

[ralph]

Here is an interesting couple of solutions.
http://stackoverflow.com/questions/580623/how-to-clone-an-object-in-vb6

I like them as I abuse persistance and serialization a lot.

-ralph

[ralph]

On Tue, 14 May 2013 11:43:12 -0400, "Phil Hunt" <a...@aaa.com> wrote:

>Yes, that's the way to go. UDT is nice to keep relevent data together, but
>it is not portable, eg passing/returning to fucntion.
>

Interesting method to abuse UDTs.
http://stackoverflow.com/questions/547903/self-inspection-of-vb6-udts

Declare them as Friend instead of Public.

My favorite is to just define them as structs in a type library.

-ralph

[MM]

The dictionary object is waaaaay better than a collection! I can do no
better than quote from Ken Getz/Mike Gilbert's Visual Basic Language
Developer's Handbook:

"Why is a Dictionary Better than a Collection?

The Dictionary object fixes several of the glaring errors in the
design of the VBA Collection object -- errors that continue even after
several versions. Perhaps the VBA team doesn't see these issues as
'errors', but they make the Collection object difficult, if not
impossible, to use. In specific,

- You can add items to the dictionary using the Item property. That
is, you can write code like this, to add a new word and initialize its
count in a dictionary named dct:
dct.Item("NewWord") = 1

- You can retrieve both keys and items, given a Dictionary object.
That is, because of the Items and Keys properties, you can retrieve
items from either array. In a collection, you can only retrieve the
items, not the Key values. For example, you might write code like this
to iterate through a Dictionary object, printing out the keys and
values:
Dim i As Integer

For i = 0 to mdct.Count - 1
Debug.Print mdct.Keys(i), mdct.Items(i)
Next i

- You can modify a key once it's been added to the dictionary. For
example, imagine Excel's workbook, a collection of worksheet objects.
Each worksheet must have a unique name within its collection (that is,
the Name property acts as the Key value within its collection), yet
you have always been able to change the Name property of a worksheet.
Using a Collection object, the Key property of an object is write-only
and write-once. If you need to change the Key value, you must delete
the item from the collection and then re-add it with the new key.
Using a dictionary, you can modify the Key property at any time (the
value must continue to be unique within the Dictionary object,
however). For example, to change the Key property from "lowercase" to
"UPPERCASE", you might write code like this:

dct.Key("lowercase") = "UPPERCASE"

From then on, the item associated with the key "lowercase" would now
be associated with the key "UPPERCASE" instead.

- You're not limited to using strings as the Key values for items in a
dictionary. In a collection, each object can either have no Key value,
or a unique string value. In a dictionary, each object must have a
unique Key value associated with it, but that key can be of any data
type.

- A Collection object provides no easy way to determine if a
particular item has already been added to the collection. The
Dictionary object provides the Exists method, which returns True if
the specified Key value already exists within the dictionary.

- A collection provides no obvious way to remove all its items. The
Dictionary class provides a RemoveAll method, effectively resetting
the dictionary."
(end of quoted segment)

I find the Dictionary is far superior. Sure, it might not be
*necessary* to use every single feature of a Dictionary in a specific
application, but I'd rarther standardise on usage across a range of
apps by concentrating only on the Dictionary object.

For another take on the differences between Dictionary and Collection,
see
http://www.nullskull.com/a/740/cool-features-of-visual-basic-60-objects.aspx

MM

[MM]

The PropertyBag concept only applies if one is developing ActiveX
controls/documents, yes? I'm not (yet) using a user control, just a
plain old 3rd-party control on top of a standard PictureBox.

Using the 3rd-party control, SeeThroughPictureBox, quickly enables me
to display a picture or a symbol on top of another picture or surface
so that you can see through the transparent parts to the underlying
picture. In my case I'm printing a musical note from a public domain
TTF music font to the SeeThroughPictureBox, then at runtime I can move
the note in any direction I like and the bits around the note are
transparent, allowing the staff to show through.

MM

[Eduardo]

"ralph" <nt_con...@yahoo.com> escribi� en el mensaje
news:0pm4p8hfgvrlrpo0e...@4ax.com...

Thanks. That opens for me a new tool to avoid writing custom functions to
accommodate data for storing things in the registry.
I guess that you could save bitmaps and any type of information that you can
put into a propertybag, and the output is serialized into a string.

[Henning]

"MM" <kyli...@yahoo.co.uk> skrev i meddelandet
news:8io4p8h8c5605mcpj...@4ax.com...

Dim pbtmp As Variant
Dim PB As New VBRUN.PropertyBag

PB.WriteProperty "Bs_Idx", BS_Idx, 0
....
pbtmp = PB.Contents
If SaveFile(pbtmp) Then

/Henning

[Henning]

"Henning" <comput...@coldmail.com> skrev i meddelandet
news:kmtp1u$p5k$1...@dont-email.me...

Just to clarify SaveFile...
Private Function SaveFile(data As Variant) As Boolean
Dim fp As Long

With CommonDialog1
On Error GoTo ErrHandler
' Set filters.
.Filter = "(.pbg)|.pbg"
' Specify default filter.
.FilterIndex = 0
' Display the Open dialog box.
.ShowSave
' Call the open file procedure.
fp = FreeFile
Open .FileName For Binary As #fp
Put #fp, , data
Close #fp
SaveFile = True
End With
Exit Function
ErrHandler:
' User pressed Cancel button.
SaveFile = False
End Function

/Henning

[CoderX]

"MM" <kyli...@yahoo.co.uk> wrote in message
news:nuk3p8lkb8k3sbug1...@4ax.com...

> On Mon, 13 May 2013 16:08:48 -0300, "Eduardo" <m...@mm.com> wrote:
>
> Aarrrrggghhh! Please, NO Collection! The Dictionary object is streets
> ahead in terms of functionality. It works brilliantly the way I am
> using it for storing extra data about the control array elements I am
> manipulating at run time. I store the Dictionary key in the Tag
> property and a UDT ( based on a class) in the Dictionary's item. For
> unique keys I'm using GetTickCount.

Eddie apparently does not like change.

[Mayayana]

| I'm not entirely happy with the "quick solution" you say some admins
| have adopted. What if one of their own programmers needed to use some
| component the admins had simply removed?

It's not a quick solution. There was a lot of mixed
feeling when MS expanded script into the WSH, thus
rendering IE forever unsafe. WSH was really aimed at
admins, but many felt that the whole design, using
browser script, was insecure. Those admins don't have
"programmers". They are the programmers. In other
words, it's people running corporate networks who
don't want the workstations to be able to run unsafe
code.

[BeeJ]

Eduardo was thinking very hard :
> "ralph" <nt_con...@yahoo.com> escribiￜ en el mensaje

> news:0pm4p8hfgvrlrpo0e...@4ax.com...
>> On Tue, 14 May 2013 11:40:03 -0300, "Eduardo" <m...@mm.com> wrote:
>>
>>>

>>>"ObiWan" <alb.20.t...@spamgourmet.com> escribiￜ en el mensaje

>>>news:20130514163...@deathstar.mil...
>>>>
>>>>> > not only store data linked to the "tag" but to also be able to
>>>>> > persist/reload them with ease
>>>>
>>>>> Where do you save the PropertyBag from one run to another?
>>>>
>>>> I suppose you used PBs, didn't you ? If so, you should exactly know the
>>>> "save" options you have (and those even include alternate data streams
>>>> if you really want to go that deep)
>>>
>>>I only used them in UserControls for design time data storage, and it's
>>>handled automatically by VB.
>>>
>>
>> Here is an interesting couple of solutions.
>> http://stackoverflow.com/questions/580623/how-to-clone-an-object-in-vb6
>>
>> I like them as I abuse persistance and serialization a lot.
>
> Thanks. That opens for me a new tool to avoid writing custom functions to
> accommodate data for storing things in the registry.
> I guess that you could save bitmaps and any type of information that you can
> put into a propertybag, and the output is serialized into a string.

All except objects in the Propertybag?

[MM]

Sounds to me like father disabling 4th gear so that son can't kill
himself in his first car.

MM

[MM]

I don't want to save the data in a file!

MM

[ObiWan]

> I don't want to save the data in a file!

once you have your data into the propertyBag (structured storage) you
may just pick the PB "blurb" and stuff it wherever you want, be it a
file, a database column, a registry entry or whatever floats your
boat... heck, you may even convert the blurb to "base64" and "POST" it
to a webserver :)

[Eduardo]

"BeeJ" <nos...@spamnot.com> escribi� en el mensaje
news:kmuord$3bq$1...@dont-email.me...

> Eduardo was thinking very hard :

>> "ralph" <nt_con...@yahoo.com> escribi� en el mensaje

>> news:0pm4p8hfgvrlrpo0e...@4ax.com...
>>> On Tue, 14 May 2013 11:40:03 -0300, "Eduardo" <m...@mm.com> wrote:
>>>
>>>>

>>>>"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje

>>>>news:20130514163...@deathstar.mil...
>>>>>
>>>>>> > not only store data linked to the "tag" but to also be able to
>>>>>> > persist/reload them with ease
>>>>>
>>>>>> Where do you save the PropertyBag from one run to another?
>>>>>
>>>>> I suppose you used PBs, didn't you ? If so, you should exactly know
>>>>> the
>>>>> "save" options you have (and those even include alternate data streams
>>>>> if you really want to go that deep)
>>>>
>>>>I only used them in UserControls for design time data storage, and it's
>>>>handled automatically by VB.
>>>>
>>>
>>> Here is an interesting couple of solutions.
>>> http://stackoverflow.com/questions/580623/how-to-clone-an-object-in-vb6
>>>
>>> I like them as I abuse persistance and serialization a lot.
>>
>> Thanks. That opens for me a new tool to avoid writing custom functions to
>> accommodate data for storing things in the registry.
>> I guess that you could save bitmaps and any type of information that you
>> can put into a propertybag, and the output is serialized into a string.
>
> All except objects in the Propertybag?

For saving objects you first need to serialize them in some way.
It's a "limitation" that is common to any save method.

[Schmidt]

Am 15.05.2013 10:02, schrieb Eduardo:

>> All except objects in the Propertybag?
>
> For saving objects you first need to serialize them in some way.
> It's a "limitation" that is common to any save method.
>

VB6 supports the IPersistStream-Interface for (Public) Classes
(defined in a Dll-Project).
To enable that Interface in the IDEs Class-PropertyGrid, one
can set the Class-Property 'Persistable' to 1.

After that, two new Events are available (in Addition to
the Standard- Class_Initialize and Class_Terminate):

Private Sub Class_ReadProperties(PropBag As PropertyBag)
'serialize your Class-State (from m_MyProp1, m_MyProp2, ...)
End Sub

Private Sub Class_WriteProperties(PropBag As PropertyBag)
'deserialize your Class-State (into m_MyProp1, m_MyProp2, ...)
End Sub

The nice thing about those classes is, that they "AutoSerialize"
as soon as they are Put into an "outer" PropertyBag (here I'm
not referring to the internal one, which comes as a Parameter
in the above Events).

PBOuter.WriteProperty "MyAutoSerializeClass", oMyClass

And the same "Single-Line" approach for the Read-Direction
(doing an AutoInstantiation and the AutoDeserialization):

Set oMyClass = PBOuter.ReadProperty("MyAutoSerializeClass")

As said, disadvantage is, that this mechanism is only available
for Public Classes, hostet in their own Dll-Project(s).

Olaf

[Mayayana]

| > It's not a quick solution. There was a lot of mixed
| >feeling when MS expanded script into the WSH, thus
| >rendering IE forever unsafe. WSH was really aimed at
| >admins, but many felt that the whole design, using
| >browser script, was insecure. Those admins don't have
| >"programmers". They are the programmers. In other
| >words, it's people running corporate networks who
| >don't want the workstations to be able to run unsafe
| >code.
|
| Sounds to me like father disabling 4th gear so that son can't kill
| himself in his first car.
|

Something like that. For corporate admins the task is to
keep everything functioning and up-to-date, while preventing
the employees from changing anything or getting into
trouble. That's why there's "user mode" in Windows. That's
not news. Anyone who doesn't run as admin is disabling
their own functionality for the sake of stability and security.
Microsoft is their admin. (And as Deanna will tell you, anyone
who's *normal* runs that way. :) Corporate admins have more
options to customize exactly how their workstations function.
Like Junior who gets to use the car only as needed, the
employees are kept out of trouble by locking them out of
everything but MS Word and their personal folder. Things like
WSH were never meant for use by the average computer user.
VBS and JS files are morel ikely to be blocked by AV than are
EXE files for that reason.

The anti-WSH school makes more sense if you think back
to the late 90s. Script pre-1998 was little more than a way
to provide dynamic events in webpages. With WSH, MS added
CreateObject and ActiveXObject methods, which married script
to the OS, allowing it to use any compatible COM object. The
WSH people also cobbled together basic functions they thought
admins might need, in scrrun.dll and wshom.ocx. And a lot of
script attacks resulted. VBScript is often equated with
malware to this day. (MS made the same mistake over again
ActiveX and with CSS, allowing "behaviors" [external script files]
to be added as CSS properties. And the rest is history. Now we
have so-called HTML5 webpages that are really nothing more
than javascript-based software running with unknown remote
connections and limited security in a browser window.)

So before WSH there was a lot less browser risk, and a lot of
people at the time thought MS had made a gigantic blunder in
allowing script to connect to anything outside the browser window.
I think there were also mixed feelings about GUI tools. WSH was
meant to be the equivalent of DOS batch scripts for the "modern"
GUI OS. But a lot of admins like the esoteric and incantation-like
qualities of command-line. GUI is for civilians in their minds. Even
to this day people suggest DOS scripts in scripting forums. MS
creates confusing command-line tools to block the mainstream
from specific functionality. And MS created PowerShell to
mimic Linux console functionality. Partly that must have been to
make it easy for Linux fans to switch to Windows servers, but it's
also for admins who feel like sissies when they use sensible,
convenient GUI tools. WSH has even been "deprecated", making
the console window of the 90s au courant for all geek
fashionistas... And it's a great way to impress and confuse your
friends.

[ObiWan]

> Something like that. For corporate admins the task is to
> keep everything functioning and up-to-date, while preventing
> the employees from changing anything or getting into

into a maze or worse, by installing stuff which carries "toolbars" or
some less-benign stuff; never underestimate the level which some
computer illitereate may reach; it isn't their fault, by the way, but,
as an admin you will absolutely need to deal with that (or face some
kind of hell)

> not news. Anyone who doesn't run as admin is disabling
> their own functionality for the sake of stability and security.
> Microsoft is their admin. (And as Deanna will tell you, anyone
> who's *normal* runs that way. :) Corporate admins have more

not just windows, running whatever *nix as "root" would expose you to
the very same kind of issues and that's why some *nix systems will show
you a "red desktop" (or something like that) when you log onto them as
"root"; all in all, running stuff as "the mighty power of all" may be
cool and avoid the need to fiddle with stuff and permissions, but it's
basically a brain-dead approach... like the one taken by folks which
disable whatever firewall and antivirus and whatever else and give full
permissions to whatever subfolder (or even a full partition) just
because their "blog app" (or whatever else, pick your own) doesn't work
as expected :P