I have some conditionals in my InitializeComponent which affect the layout based on some variables. Unfortunately, it seems like whenever I rebuild my application, this code is reverted back to its previous state. Is this code being regenerated based on the Designer interface? Is there a way to prevent it from doing this?
Yes, InitializeComponent is completely IDE-generated; don't even try to mess with it.
If you have conditional logic wherein you want to add/remove some controls, do it in your control's constructor after the auto-generated call to InitializeComponent.
Note that if the conditional stuff will depend on features enabled/disabled at design time (e.g., if someone else is using your control and you've provided properties to affect how that control behaves which you intend to be set at design time), using the constructor won't work since the constructor will have already run by the time the user makes his/her choices from the design view; in this case, override the OnLoad method and put your logic in there (or do some variation of this, e.g., handle the Load event itself—there are plenty of ways to skin this cat).
Related
new to .net coming from vba decided to rewrite a management app using vb.net and SQL Server.
Started writing the base library for my application.
I created custom controls to use in my application that would expose a Zoom function, background color for the current active control a .modified property similar to the one available in textbox and some extra other properties (SQLTableName, SQLColumnName, ...) to enable iterating through a container (form) for modified controls and Update/Insert into a SQL table via a SQLProcessClass.
Concurrently I'd like to also implement a simple undo functionality.
My first idea was to add a PrevValue variable set in the OnEnter event if the Modified property is False, exposing an OldValue property and an Undo method in the custom controls.
However I found that the TextBoxBaseClass already exposes an Undo method and that there is an UndoEngineClass available.
Unfortunately the vs helpfile does not give examples of how to use / implement that class.
Could someone explain the usage of the UndoEngine class non-textbox controls and if it is advisable to use it or rather write my own (as I first intended to do - I also found some interesting articles about undo/redo classes) but why reinvent the wheel in case .net already provides a class for it.
thks
In VB.NET, is there a way to execute code after any event for which I have written an explicit handler, other than placing a call as the last line of each individual event handler? In ASP.NET I can put code in PreRender but there is no equivalent of that in VB.NET because there is no page life cycle.
I understand that for desktop apps the model is very different and that PreRender doesn't fit the desktop model but I hoped it would illustrate what I meant. In ASP.NET I often determine whether controls are visible, or enabled, in PreRender, after events have been processed and the underlying database has changed as a result. It seems reasonable to want to do something similar in VB.NET - multiple events can alter the underlying database, and multiple controls may need refreshed as a result, so write a routine that determines the visibility and enablement of the controls, and call it after explicitly-handled events have been dealt with.
I've tried the form validating/validated events but can't make them work.
It looks as if there is no IsLoaded property in a UserControl object in XAML, even if the Loaded event is there.
But the MSDN page on IsLoaded tells that it should be there since UserControl derives from FrameworkElement.
So I guess it was removed in XAML (the doc is for WPF). But I can't believe they just deleted it in WinRT, they must have replaced it with something else?
So, question:
How do I gain access to the IsLoaded boolean of a UserControl in WinRT?
Of course, it is always possible to do it by hand on every user control by registering a callback on the Loaded event, but it is a pain for such a simple thing.
There is no FrameworkElement.IsLoaded in Silverlight either, and WinRT is much closer to Silverlight than it is to WPF.
As to why it was removed, I can make an educated guess based on the documentation of the WPF property:
From a newly constructed FrameworkElement, this property starts off
false, and remains true after it is set to true, even if the element
is subsequently removed from a connected logical tree by code. true
state is set by the general presentation logic when elements are
loaded into the presentation engine.
Basically, the property in WPF is sometimes wrong. A control can load (and fire its Loaded event) multiple times, and be unloaded in the meantime. The WPF IsLoaded property can says a control is loaded even when it's not really. That's... very bad.
They probably removed it rather than fixing it because of at least one of these reasons:
They didn't want to break compatibility within WPF to older versions, or have a property which acts differently in WPF vs SL / WinRT
Tracking whether something is loaded or not is difficult and easy to get wrong, and so is inherently dangerous
Querying the loaded state of a control might be bad practice / a bad idea anyway
If you really do want to implement it yourself, then at least listen to Unloaded as well as Loaded. But I think that depending on what you're trying to do, there might be a better solution.
A "Loaded" control is simply one that is in the visual tree, so you could check if there is a path between your control and the RootVisual of the application using VisualTreeHelper, but it might not be very efficient and I would still recommend handling the event. You could implement an attached property/behavior that would give you a bindable IsLoaded property if you really need it often.
There is no IsLoaded property in the Windows Runtime version of the framework. As you point out, the link you provide is not for the Windows Runtime. For that, see this MSDN link: FrameworkElement.
The Loaded event seems to be the only way to do what you are asking.
I have two controls. The XAML's are big and very similar. One difference is this: they contain a listbox, in one control, it's bound to {StaticResource X}, and is multiselect, the other is bound to {StaticResource Y}, and is not multiselect. The code-behinds are also very similar. How should I combine these two classes into one? I thought about creating a base class and deriving my 2 controls from it, but I have no idea how to do that with XAML. I know I could make it easier if I set the differing properties in code instead of XAML (in which case the XAML's would become identical), but let's consider that plan B. Silverlight has no StyleSelector, it seemed like a possible solution though. Maybe VisualStateManager could do it, except it sounds bad, because my problem has nothing to do with visuals, but maybe I could define 2 states anyway. Except I think SL doesn't support binding in style definitions. Tough question for a beginner like me...
You should look into creating custom controls and using AlternateContent properties. Look these up and you'll find hundreds of tutorials.
Here's a quick google search to get you started with alternate content.
So, to sum it up, I want one control which can work in somewhat different modes, or states. The mode can affect XAML properties and code logic, too.
It seems like VisualStateManager is very limited in which properties it can manipulate. But when the differences are only visual, it's the best choice.
When there are other differences in XAML, then the obvious choice is to omit those properties from XAML and set them in code, like in the ctor. A nicer way is to expose those properties as dependency properties in code, bind to those properties in the XAML of the user control, and then you can specify those properties in other XAML's where you use this user control. When your control doesn't care what's in those properties, then it's a good design choice, too. In my case, though, when setting up those differing properties should be the responsibility of the user control itself, not its parent, and I want to expose a single mode property only, it's not good.
For this case, the best way I found so far is this:
create a normal user control (XAML+code), expose the differing properties (simple, not DP's) and bind to them in XAML
make this user control abstract, and possibly some properties, too
for each different mode the control needs to support, derive a class from this base control (code only, no XAML), provide implementations for the abstract properties
instead of using the base control in other places, use one of the derived implementations
This way, you can easily specify from outside which mode you want your control to work in. The drawback is that it's not easy to change the mode, since it's not a property you need to change but the type and instance of the control.
And finally, when there are code logic differences, too, then one way is exposing a mode property, or using the abstract class method I described above. For example, a button click handler function can be abstract, too.
On the Compact Framework, the System.Windows.Forms.Timer class doesn't support the system.componentmodel constructor:
new Timer() is supported: http://msdn.microsoft.com/en-us/library/aa335543(v=vs.71).aspx
new Timer(IContainer container) is not supported: http://msdn.microsoft.com/en-us/library/aa335544(v=vs.71).aspx
This means that, when I add a Timer to a Form in a CF app, it does not get added to the form's IContainer components field, so it doesn't get auto-dispose()d when the form is dispose()d.
Why is this not supported?
How should I best dispose of Timers when my form is disposed? It seems that I have two main options:
move the form's dispose() method from the .designer.cs into my main .cs file and add a manual "_timer.dispose()" call in there
or manually add the Timer object to the components collection on form creation, after InitializeComponent() has been called
Which should I prefer? If I forget to do one of these two, the Timer will live forever, keeping my form alive (because the Timer can't be GCed, and it holds a reference to my form's Timer_Tick() method, so the form can never be GCed).
Does this implementation decision reflect some strangeness about Timers and Disposing on CF machines which I need to be aware of?
I'd vote for option 3: don't add the Timer through the Form Designer; instead add it manually in code and add it to the components collection manually as well.
My reasoning for this follows like this:
Mucking with the designer code is just generally a bad idea, so your first option has a code smell to it
Adding it to the components collection manually is highly prone to future developers (even yourself in a few months) no understanding why it's there and getting axed.
I generally don't like "mixing" object initialization. If the disigner is doing initialization of an object, it needs to do all of it or none of it, never just part. Having it do some partial work is deadly when the code is maintained or during reuse when someone does a copy & paste into some other class.