[RESOLVED] [VB6] - about properties

[joaquim]

i need understand 1 bug in properties: why, when we change the value, these value isn't saved(after close the form and then open it, in design mode)?

[LaVolpe]

Two things should happen when your Let or Set Property is called:
1) You add this before exiting the property: PropertyChanged "propertyName"
2) In the uc's WriteProperty event, you must write to the property bag, the properties you want saved
See this PDF document. It is a huge help for people developing ActiveX controls.

[joaquim]

Two things should happen when your Let or Set Property is called:
1) You add this before exiting the property: PropertyChanged "propertyName"
2) In the uc's WriteProperty event, you must write to the property bag, the properties you want saved
See this PDF document. It is a huge help for people developing ActiveX controls.

thanks for the manual
see the code:

Public Property Get TransparentColor() As OLE_COLOR
    TransparentColor = lngTransparentColor
End Property

Public Property Let TransparentColor(ByVal vNewValue As OLE_COLOR)
    lngTransparentColor = vNewValue
    Call ShowImage
    PropertyChanged "TransparentColor"
End Property

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "TransparentColor", TransparentColor, lngTransparentColor
end sub

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   TransparentColor = PropBag.ReadProperty("TransparentColor", lngTransparentColor)
end sub

isn't the 1st time, but i don't understand why these bug

[joaquim]

i belive that i correct the bug... but tell me what heather is correct:

PropBag.WriteProperty PropertyNameInString, VaribaleName, defaultvalue
or
PropBag.WriteProperty PropertyNameInString, PropertyName, defaultvalue
?

[LaVolpe]

i belive that i correct the bug... but tell me what heather is correct:

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "TransparentColor", lngTransparentColor, DefaultValue
end sub

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   lngTransparentColor = PropBag.ReadProperty("TransparentColor", DefaultValue)
end sub

Replace DefaultValue, above, with whatever lngTransparentColor starts out as in a new control. What VB does is compare the value you want saved and the default value. If they are the same, nothing is written. This is why you need to include the DefaultValue when you read the property too. Because if nothing was written, the DefaultValue is returned else the written property.

[joaquim]

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "TransparentColor", lngTransparentColor, DefaultValue
end sub

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   lngTransparentColor = PropBag.ReadProperty("TransparentColor", DefaultValue)
end sub

Replace DefaultValue, above, with whatever lngTransparentColor starts out as in a new control. What VB does is compare the value you want saved and the default value. If they are the same, nothing is written. This is why you need to include the DefaultValue when you read the property too. Because if nothing was written, the DefaultValue is returned else the written property.

then, like i see your code, is VariableName and not PropertyName... right?
(i correct my bug seeing these)

PropBag.WriteProperty PropertyNameInString, VaribaleName, DefaultValue

[LaVolpe]

Yes, but better wording, I think, would be
PropBag.WriteProperty PropertyNameInString, CurrentPropertyValue, DefaultPropertyValue
CurrentPropertyValue = PropBag.ReadProperty(PropertyNameInString, DefaultPropertyValue)

And propertyname is just a key, it can be anything and doesn't have to be the actual name of the property. Instead of "TransparentColor" you could have used "tColor", "Trans", anything. It is easier to follow the code if it is named same as the property though.

[joaquim]

Yes, but better wording, I think, would be
PropBag.WriteProperty PropertyNameInString, CurrentPropertyValue, DefaultPropertyValue
CurrentPropertyValue = PropBag.ReadProperty(PropertyNameInString, DefaultPropertyValue)

And propertyname is just a key, it can be anything and doesn't have to be the actual name of the property. Instead of "TransparentColor" you could have used "tColor", "Trans", anything. It is easier to follow the code if it is named same as the property though.

thanks for that important information
for finish let me ask these: if we use PropertyName instead CurrentPropertyValue, the value isn't save, right(between the design mode and run mode)?

[LaVolpe]

Wrong. It will be saved. Sometimes people have much more code in the Property Get statements and using the value instead of the property name is more efficient.

Here's why your original code failed.
1) When writing you had this

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "TransparentColor", TransparentColor, lngTransparentColor
end sub

What happens above? You are retrieving the value from the Property Get statement because you used the PropertyName as the current property value. Then as the default value, you were using the current value. Ok? Well, what happened? They are the same value. So nothing gets written. I explained that in post#5. So....

2) When reading, you had this code:

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   TransparentColor = PropBag.ReadProperty("TransparentColor", lngTransparentColor)
end sub

What happens here? Because nothing was written during WriteProperties (because currentvalue & defaultvalue were the same), nothing will be read. And if nothing is read, the default value is used. For the default value you have lngTransparentColor and at this point in your code, its value is zero.

The above is not ideal when reading properties. By setting the .ReadProperty value to the Property name (TransparentColor ), you are actually going to trigger that property and trigger a PropertyChanged "TransparentColor" action. This means that even if no properties were changed by the user, a WriteProperties event will still be triggered. If user had dozens of these controls in their project, each time they unloaded a form in IDE, it could take a lot of time closing because all of them are re-saving even if nothing changed. Suggest setting the .ReadProperty value to the variable that keeps the property value.

Read over chapter 17 (UserControls) of that PDF document. It will help.

[joaquim]

Wrong. It will be saved. Sometimes people have much more code in the Property Get statements and using the value instead of the property name is more efficient.

Here's why your original code failed.
1) When writing you had this

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "TransparentColor", TransparentColor, lngTransparentColor
end sub

What happens above? You are retrieving the value from the Property Get statement because you used the PropertyName as the current property value. Then as the default value, you were using the current value. Ok? Well, what happened? They are the same value. So nothing gets written. I explained that in post#5. So....

2) When reading, you had this code:

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   TransparentColor = PropBag.ReadProperty("TransparentColor", lngTransparentColor)
end sub

What happens here? Because nothing was written during WriteProperties (because currentvalue & defaultvalue were the same), nothing will be read. And if nothing is read, the default value is used. For the default value you have lngTransparentColor and at this point in your code, its value is zero.

The above is not ideal when reading properties. By setting the .ReadProperty value to the Property name (TransparentColor ), you are actually going to trigger that property and trigger a PropertyChanged "TransparentColor" action. This means that even if no properties were changed by the user, a WriteProperties event will still be triggered. If user had dozens of these controls in their project, each time they unloaded a form in IDE, it could take a lot of time closing because all of them are re-saving even if nothing changed. Suggest setting the .ReadProperty value to the variable that keeps the property value.

Read over chapter 17 (UserControls) of that PDF document. It will help.

thanks for the information my friend

[joaquim]

in UserControl_ReadProperties, what is a diference between:

FileName = PropBag.ReadProperty("FileName", "")

and

strFileName = PropBag.ReadProperty("FileName", "")

????
(like you see the strFileName and FileName is the property name)

[LaVolpe]

The difference is that if FileName is a property, it will activate all the code behind the Let FileName property. Setting it to the strFileName will not activate the property. Setting it to FileName is the same as if a user set the FileName property in the property sheet or during runtime.

[joaquim]

The difference is that if FileName is a property, it will activate all the code behind the Let FileName property. Setting it to the strFileName will not activate the property. Setting it to FileName is the same as if a user set the FileName property in the property sheet or during runtime.

thanks. beause i have seen that if i use strFileName, it can't save the value, but if i use FileName, save it.
we must use the same for writeproperties?
in these property, but in others don't save.. i don't catch these stupid bugs:'(
realy. i know what to do, the properties works perfetly, but they don't catch well in UC write and read events... i don't understand.. sorry
but something isn't right... a read very information, but don't about these aspects... maybe that's the VC++ 6 and the VB 2008 catch that stupid errors and i can't see the custom property.... i dont' understand these... these don't make sence... sorry
thanks

[LaVolpe]

thanks. beause i have seen that if i use strFileName, it can't save the value, but if i use FileName, save it.
we must use the same for writeproperties?

That's not true. Either 1) you are setting strFileName to something else somewhere else in your code, or 2) you are not processing the file when your Show event is called.

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
   PropBag.WriteProperty "FileName", strFileName, vbNullString
end sub

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
   strFileName = PropBag.ReadProperty("FileName", vbNullString)
end sub

Look at your previous thread, post #9, regarding the Show event.

As a rule, you load all your properties into their uc-level variables. Once you get your uc Show event, then you create what is needed, resize if needed, and paint your uc. As it is now, it appears many of your properties do a bunch of processing. Since you are not calling your property by reading the propertybag value into the variable, the code in the property LET isn't run. You wrote your properties incorrectly in my opinion. The code in the properties should not modify your control. Rather, it should call other routines that modify the control. This way, when the the Show event is first called, it could call those same routines.

If you are going to leave it the way it was and call your Property names when reading from the propertybag, then there are downsides as I mentioned before: 1) The control, when closing, will re-save all of its properties even if no properties changed. This is because in each of those properties you are calling, there is a PropertyChanged being triggered. 2) If any of those properties refer to its parent, extender, or ambient properties, it is possible the control is not sited during ReadProperties event, and you'll get an error. In that case you'll have to add error trapping, but the control probably won't be displayed anyway because of the errors. The control will always be sited during the Show event.

To be sited on a container. This means the control has its own independent user interface that is contained on the window of another application, be it a form in Visual Basic or a Web page on an Internet browser. The control is able to interact with the container application in a variety of different ways.

... during the Show event, during which it is safe to assume (at least with Visual Basic) that all of the other controls belonging to the container have already been sited.

During the INITIALIZE event you may not:
Access the Extender or Ambient properties of the UserControl object or any
of their properties. This is because while your control object does exist at
this time, it has not yet been placed on the container (or, as they usually
phrase it, the control has not yet been sited at this time).

During the INITPROPERTIES event you should not:
- Display anything. The control will not yet be visible at this time.
- Perform operations that depend on the size of the control. The control and
container may not yet be at their final size.
- Perform operations that assume that the control window is actually present
on the container. Examples of these include API functions that manipulate
windows. The control window is not actually on the container during this
event (though from the point of view of the object relationships, it has
already been sited).

During the READPROPERTIES event you may:
- Perform most of the initializations that depend on the container. The control
is already sited when this event occurs, thus the Extender and Ambient
properties are valid.

During this event you should not:
- Display anything. The control will not yet be visible at this time.
- Perform operations that depend on the size of the control. The control and
container may not yet be at their final size.
- Perform operations that assume that the control window is actually present
on the container. Examples of these include API functions that manipulate
windows. The control window is not actually on the container during this
event (though from the point of view of the object relationships, it has
already been sited).

Note about above. When control is displayed in another environment (not Visual Basic), I have experienced errors when trying to access Ambient/Extender properties. I have never had this problem in Visual Basic thought.

During the SHOW event you may:
- Perform any operations that you would like a Web-based control to do when
the user returns to the page containing the control.
- Set a flag variable to indicate that your control has, in fact, been sited on a
container. Some development environments do not site controls at design
time. This will be discussed further in the section describing the Paint event.
- When this event occurs (at least on VB5), all of the other controls on a form are sited and the form's Load event has executed. This differs from the
ReadProperties event, which guarantees only that your control is sited. If
your control must interact with other controls on a form (which is not
recommended), this is probably a safe time to do so, though this behavior is
not guaranteed for every container.

And here's the link again to Dan Appleman's book:
http://www.google.com/url?sa=t&sourc...rtotVtf8Uj3F5w

[joaquim]

with hard work, but now i can padron my properties.
but still not block that erros in VB 2008
that the object don't have that property\method and some properties aren't showed
for the padron properties work perfetly, i initializate the properties in Usercontrol initializate event.
i will try do anotherthing for try block that stupid errors in others OOP.
thanks