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)?
Printable View
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)?
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:
isn't the 1st time, but i don't understand why these bug:(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
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
?
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.Code: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
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.
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
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....Code:Private Sub UserControl_WriteProperties(PropBag As PropertyBag)
PropBag.WriteProperty "TransparentColor", TransparentColor, lngTransparentColor
end sub
2) When reading, you had this code:
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.Code:Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
TransparentColor = PropBag.ReadProperty("TransparentColor", lngTransparentColor)
end sub
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.
in UserControl_ReadProperties, what is a diference between:
andCode:FileName = PropBag.ReadProperty("FileName", "")
????Code:strFileName = PropBag.ReadProperty("FileName", "")
(like you see the strFileName and FileName is the property name)
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
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.
Look at your previous thread, post #9, regarding the Show event.Code: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
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.
Quote:
Originally Posted by Dan Appleman
Quote:
Originally Posted by Dan Appleman
Quote:
Originally Posted by Dan Appleman
Quote:
Originally Posted by Dan Appleman
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.Quote:
Originally Posted by Dan Appleman
And here's the link again to Dan Appleman's book:Quote:
Originally Posted by Dan Appleman
http://www.google.com/url?sa=t&sourc...rtotVtf8Uj3F5w
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