 |
|
 |
You're "history section" lists all the dates as 2005.
Cool work, BTW! Got me thinking on how to add this capability to a MyXaml generated form.
Marc
XPressTierSome people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson People are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
|
|
|
|
 |
|
 |
Thanks Marc, I will correct it.
|
|
|
|
 |
|
 |
hi,
U've done a great work, but I have a question: there's a way to modify the project in order to get the style application at design time? (I would like to see the style applied immediatly in the visual studio editor)
thank U in advance,
Emanuele
|
|
|
|
 |
|
 |
Not actually but I'll try to do it in a next version.
About this, is there anyone who know how to display a STATIC property in the property grid of a designer. By default, the static properties are hidden. I suppose there is a little magic attribute to apply to the property but I don't know anymore.
|
|
|
|
 |
|
 |
The obvious way of having that done is to add an instance property to the class which would be mapped to the static field. But I suppose you'd prefer to avoid this... I think the real solution lies somewhere around the TypeDescriptor[^] type. As stated in MSDN:
The extensibility provided by TypeDescriptor allows the design-time representation of a component to differ from its actual run-time representation, which makes TypeDescriptor useful for building design-time infrastructure.
This means that by using a custom type descriptor, you can expose a design-time only "property" which maps to the static field (or to anything you want: method, other object, ...).
To be able to provide your custom type descriptor, you must decorate your class with TypeDescriptionProviderAttribute, then build a TypeDescriptionProvider whose method GetTypeDescriptor will in turn give back an instance of your custom type descriptor (which will implement ICustomTypeDescriptor or be derived from CustomTypeDescriptor)...
Hope this helps.
PS: why do you need to show static fields in a property grid? This can be rather disturbing: modifying one object's property will affect all the others...
|
|
|
|
 |
|
 |
Thanks to you Olivier but I found another way to do it.
Q : Why do I need to show static fields ?
A : I wanted to have just one filename for all the forms of the application.
=> I found another to do it : store the value of the 'StylesSheetFilename' property in the app.config file (this property becomes read only).
|
|
|
|
 |
|
 |
I got it.
Indeed, this seems much more a correct solution to your problem. Having to expose a static property via instances suggested a design flaw.
|
|
|
|
 |
|
 |
thank U for the new modifications
I'll check the new version immediatly...
I think now the stylessheet manager fits perfectly to my needs.
thank U again,
Emanuele
|
|
|
|
 |
|
 |
Is this will effect the application performance because it alway takes time to look up the xml, and is this the similar way of globalization/localization (just like the netbeans do) ? Is that possible maintain the label with different language in your xml?:->
Develop with pleasure
|
|
|
|
 |
|
 |
In "Using the component", $1, I use the "Text" property only for an example, to demonstrate that you can manage all property of a control but I didn't realize this component to manage labels with different languages (only styles). I don't think this is the same usage. Perhaps, you can use it like this but ...
Concerning the performance, I didn't really test so sorry but I can't answer you.
|
|
|
|
 |
|
 |
yancyn, I think about what you tell me on performance and decide to modify the StylesSheetManager like this :
* the StylesSheetFileName property is now static (unique for all the component dropped on the form and so unique for all the forms so the whole application)
=> this property must be explictly defined on the code (not in the designer)
* the ApplyStyles must be expliclty called to apply the styles on the form
=> when calling this method, I watch if the StylesSheetFilename has changed from the previous call.
* If yes, I load the file and put the styles in cache
* If no, I use the styles "in cache"
So, if you set the styles of your application in the load of your mainform, the styles sheet file will be used only once. When a new form will be open, the styles "in cache" will be use.
Tell me if you see another thing I can do else I think I will put this new version in the week end.
|
|
|
|
 |
|
 |
This is a very elegant solution and I noticed how you ignore complex properties ... but how would you handle them if you had to?
Matt
-- modified at 17:23 Friday 14th July, 2006
|
|
|
|
 |
|
 |
In the next version of the component, I will handle the indexed properties. This permits to write something like dgDataGrid.Columns[1].HeaderText = "Text".
In fact, if the property name is indexed (contains something like this "[1]"), I call the PropertyInfo.GetValue() method with the property name (without "[1]") and then cast the result in IList (only indexed properties which implement IList interface are supported) which permits me to use "[x]" syntax. If you want more, feel free to see the PropertySetter.GetObject() method.
I hope I reply to your question.
|
|
|
|
 |
|
 |
I have been thinking about doing something like this. The company I work for uses the Infragistics Control Suite which now allows skinning of Win controls. However, simple properties such as form backcolor are not supported. Also when deploying the application there are numerous library DLL's that are required. Nice Job.
|
|
|
|
 |