I'm making a custom control.
Basically what I'm looking for is a OnPreInit event in custom controls. I basically need to know that all of the controls that will be loaded of type MyCustomControl are constructed or not.
Ok, so basically I need to know in the constructor if the current instance being constructed will be the last.
Note: My custom control contains other controls(though this isn't guaranteed) but it will not contain controls of MyCustomControl class.
I've thought about doing an override of AddParsedObject. But if the instance of my custom control doesn't contain any controls, will this still get called?
Unfortunately the approach you're describing is "non-trivial". That means it might not be technically impossible, but so difficult to do correctly and has so many negatives/downsides that you will be better off stepping back and analyzing the larger problem for a different design. Perhaps if you re-posted articulating the end goal you're trying to accomplish, we can help you find an approach that is viable.
I hate to say use a counter, but you're either going to have to pass state information through a dedicated class (or the context,) which you could do in the constructor of the control prior to testing if you've got as many as you need, or you could do a recursive walk through Page.Controls and their .Controls and test each one for type....
Related
Apologies if I'm grossly overlooking something here, but I'm a bit stumped:
I'm developing a set of custom controls which all should share some common DependencyProperties. Say DPropA and DPropB. I want to avoid to copy/paste the same DPs over multiple controls, however, since they are custom controls, they all already inherit from their respective base control (Button, TextBox etc.) and MI is not possible. DP are static fields, so I can't put them in an Interface either.
Also, I later may need to access some of these properties via reflection. This isn't an issue with properties that are near the top of the hierarchy (e.g. Control.FontStyleProperty), but since I can't declare a base class with my DPs this is also a problem.
How can I solve this? I'm a bit suprised I barely found something about that problem, since I thought that sharing a common set of DPs for custom controls isn't actually an uncommon problem.
In my application, different controls are only used dependent of the values of properties from a particular object. The forms constructor accept this object as a parameter.
The form has always some basic functionality, no matter what properties are set of the particular object.
Now I have something like this:
if(myObject.SomeProperty)
{
myControl.Visible = true;
myOtherControl.Visible = false;
// and so on
}
At this time, the controls that are dependant of SomeProperty are buttons and tab items. However, I can imagine that in the future other controls are added to the form and are also dependant of SomeProperty.
As you might guess, I want to set this up the right way. But I don't know exactly how. How would you implement this?
There are multiple ways I can think of solving this, depending on your situation you could select the best suited to you.
1. Databinding is one elegant solution when managing the state (visibilit or other properties) of multiple control's depend on a different object. Additional details in this question
2. You could write different functions if the combination of the states is only limited to couple of cases to at most 4-5 cases. That ways you can still reason about the methods which set the state depending on the object you are depending on. Ex: Basic_Editing, Advaced_Editing, Custom_Editiong etc.
3. If the number of cases are limited you could create multiple forms (User controls) and load them on demand based on the state of the dependent property (or object you are talking about).
Just having a bunch of if else's makes your code harder to maintain, or comprehend, logically group the states so that 1. You could reason about it later, 2.Someone else understands the reason/logic 3.When there is a change required it can be localized to one of these modular methods (techniques) reducing the time to fix, and test.
I would do it like this in form constructor:
myControl.Visible = myObject.SomeProperty && !myObject.SomeOtherProperty;
myOtherControl.Visible = !myObject.SomeProperty;
....
Is it the less code and its rapidly changing.
OR
You can create separate functions that will generate controls dynamically at runtime for each form view based on object properties.
First i can see you are setting visibility on/off it means you have already controls on the form every time.. , so that not a good practice, instead create controls only when needed.
As for your scenario you can have an function like Initialize() which contains all the code for checking if showing a particular control should be shown or not and then create it and add it to Forms control collection. If any new control come to be added later you have one function to update.
A more precise answer can be given if you can provide more detail to you scenario
Instead of using all the base wpf controls such as Label, TextBox, Grid, ect. I want to create a sub class of all these base controls and use the sub class.
e.g.
public class MyTextBox : TextBox {}
They would be dummy classes for now, but it leaves room to be expandable in-case I need to in the future. Is this recommended or is it unnecessary?
This is a text-book definition of yagni
It sounds unnecessary, unproductive, and definitely not recommended!
If for some reason you need a subclass in the future it will be much easier to simply create it then than it to do lots of unnecessary work now.
This sort of approach tends to be overkill. Where it does have its uses is when you know you will need to change the base UI controls at some point in the future. So if you were using a third party control suite then you might look at this approach, but you wouldn't want to do it with the MS controls as they are baked into the framework - you aren't going to change those!
Another approach is to ensure you follow a pattern like MVVM - this ensures that you have a UI that is nicely separated from your working code, and you can change controls with the minimum impact.
I think this is unnecessary. We can easily override the look and feel of a control using styles. In case you want to add properties, you can use attached properties.
I'm looking to hide/show properties depending on what selection the user makes in a drop. I am handling the event fine, but cannot actually make the correct properties disappear. The solutions I have found on line are mainly from 2005 and as I've had very little experience with it I thought I must be doing something wrong if hiding properties is this hard.
So far I have tried accessing the property once the event is handled but the ReadOnly and IsBrowsable properties are read only.
The propertygrid has a property BrowsableAttributes that takes an Attribute list but only works negatively and cannot do or - only and. Providing an attribute collection of ; category - 'test' and isbrowsable - true; returns those that match both and as I can't provide multiple AttributeCollections I cannot make the search specific enough to hide the necessary ones whilst leaving others visible.
I have been banging my head against a wall for the past couple of hours thinking there must be an easier way.
Have you tried applying this attribute to a property:
[Browsable(false)]
public object SomeProperty{
}
In that way SomeProperty will not appear on the propertygrid.
To do what you want to do here, you'd need to implement ICustomTypeDescriptor on your class, which is what the PropertyGrid will use to query your class/object to find out what items to display in the PropertyGrid, how to edit them, what category/description they should have, etc.
It can get quite messy, but it seems that there's a pre-written set of helper classes for you on Code Project at http://www.codeproject.com/KB/grid/PropertyGridDynamicProp.aspx.
I'd started writing my own version of the code given at Code Project and after hitting a snag I did some googling and came up with the Code Project link. It looks like they've done a lot better than I was. I've downloaded the code and it seems to work quite well.
If it doesn't solve your problem, please let me know and I'll dig a bit deeper.
I am creating huge amounts of dynamic controls, and for everything that must have an ID assigned, I assign it using a guaranteed unique variable(unless 64bits overflows from just controls).
Now, I have a problem though. I have a duplicate control somewhere and I can not discover where it is added or anything because it doesn't happen until after Page_Load, which means, it is out of my own code when an exception is thrown(I think at like Render or some other internal function).
The control name is "ctlXXX" where XXX is a number(right now, always 244) this control ID is not being made by me. It is being made by ASP.Net automatically(as none of my IDs are prefixed with ctl). So how do I correct this error that I can not see? Can anyone suggest ways of finding my error(I really hope this isn't a bug in ASP.Net)?
Also, I got the error just recently by using a Copy function which will do a Memberwise copy on a custom control, and then it will reset any controls to have either a unique ID or to be null as this part happens before controls are loaded into the custom control, which is a descendant of Panel)
Can anyone give me advice on how to find this bug?
I think you want to look at the INamingContainer interface. I think it will solve your problem but you will have to derive a new control class to do it.