We Keep Coding

What event can be used to detect when WinUI3 TeachingTip has opened or loaded

I am using a TeachingTip control in a C# WinUI3 desktop app. It mostly works OK, but I don't seem to see any event that is triggered when the control has opened (loaded) or is opening.
The control properties let me add an OnLoaded event, but that is not being triggered.
Would appreciate any pointers on adding such a handler. I note that the only listed supported events for this control are: ActionButtonClick, CloseButtonClick, Closed and Closing.
Thanks very much.

You could handle the Loaded event for the TeachingTip's root element:
<TeachingTip ...
Title="..."
Subtitle="...">
<TextBlock Loaded="OnLoaded" />
</TeachingTip>

Thank you for your response. I had supposed it would be something like this, and I may end up doing that. However, at the moment I'm using the PointerPressed handler for the element that opens the TeachingTip. It's good to know there are multiple ways to skin this cat.
Best regards.

VCL's CustomControl equivalent in Windows Forms

Delphi's VCL has a very useful class, CustomControl. This class is a direct base class of Control, which is equivalent to C# WF's UserControl.
For those, who are not familiar with VCL, CustomControl differs very little from Control; the main difference is that most of properties are protected; when implementing the new control, developer may decide, which ones does he want to publish and which ones shall remain hidden.
I'm developing my own control for Windows Forms and I want to hide some properties and events. For instance, I don't want to expose the MouseDown event - instead I allow capturing clicking on control's elements.
Is there an equivalent of VCL's CustomControl in Windows Forms? If not, how can I hide unwanted public properties and events in my control?
In response to answers:
This is not a matter of security, but rather a matter of code elegance. In Delphi I can derive from CustomControl, leave the OnMouseDown event protected (as in C#'s protected) and say to the control's user:
You cannot use OnMouseDown, because there is none. If you want to react to user clicking on control, simply use OnElementClicked - you'll even get detailed information about which element was clicked and what was its state.
I may disable calling the MouseDown event as Hans Passant suggested, but then I would have to include the following in the control's user's manual:
Please do not use the MouseDown event, because I've overridden the OnMouseDown method, such that it won't call the MouseDown event. This is because the control's logic is designed in such way, that you should use OnElementClicked rather than OnMouseDown. Please don't criticize the control because of MouseDown not working. Please don't report it as a bug, because it is by design. Please don't post messages in forums or create blog entries explaining how to fix the MouseDown problem by inheriting the class and manually calling the MouseDown event, because it would break the control's logic. Pleas don't... damnit, told you so!
If someone actually inherits from my control - I assume then, that he knows, what he's doing (also because one would then gain access to my control's internal logic as well). But if someone just uses my control, I would give him only these properties, events and methods, that I'm sure will work as designed.
I hope it explains my motives :)

There's a fundamental difference between hiding, what you asked for, and making it inaccessible, what I assume Delphi does. Hiding is simple, just repeat the declaration and apply attributes:
using System;
using System.ComponentModel;
using System.Windows.Forms;
class MyControl : Control {
[Browsable(false), EditorBrowsable(EditorBrowsableState.Never)]
private new event MouseEventHandler MouseDown;
}
Which prevents the event from being displayed in the Properties window, it won't show up in the IntelliSense dropdown and generates a compile error when he tries to assign the event in code anyway.
It is however not an absolute guarantee that the client programmer couldn't work around the restriction anyway. By casting or overriding your class for example. But the ultimate backdoor is implementing the IMessageFilter interface, nothing you can do about that. So this ought to be good enough if elegance is the goal.

Solution to remove Event handler dynamically (using reflection). Is there a better way to do this?

I need to remove event handlers from a control loaded from a dll that I don't have the code for. Since there doesn't seem to be an 'official' (i.e. supported by public methods of the .NET Framework), I was was able to create a couple extension methods that did exactly that using Reflection.
See this blog post for all the details: Removing an Event from a WinForm ListView control using reflection
Here is a code sample of how to remove the SelectedIndexChanged event (dynamically and without access to the original handler)
//for a UserControl (in fact any control that implements System.ComponentModel.Component)
var userControl = new UserControl();
//we can get the current mapped event handlers
userControl.eventHandlers();
//its signature
userControl.eventHandlers_MethodSignatures();
//remove one by using the static field name
userControl.remove_EventHandler("EVENT_SELECTEDINDEXCHANGED");
//or use this one specifically mapped to the SelectedIndexChanged event
userControl.remove_Event_SelectedIndexChanged
My question is: "is there another way?"
Although my solution works and seems stable, I'm doing internal .NET objects manipulation, so maybe there is a better solution (in 4.0 or 4.5)?
Related posts:
How would that be possible to remove all event handlers of the Click event of a Button? - uses a similar solution to mine, but I don't think their solution works

Is there a dynamic-creation-friendly LinkLabel Alternative?

I'm trying to dynamically create a link from a Windows Form to our website when certain conditions are met (it's a warning message with further information in our online manual).
Currently I'm finding LinkLabel quite unwieldy to use in this situation: having to set up LinkClicked handlers on the fly for a straightforward hyperlink seems inelegant.
Is there a wrapper or alternative that fulfills the following requirements?:
Inherits from System.Windows.Forms.Control (so I can use it in a TableLayoutPanel)
Has reasonably low setup (no strange LinkClicked function pre-visit checking, for example)
Isn't bound to a specific browser

What is your problem with the LinkClicked event handler? You would have to do the same for almost any control in order to do anything useful.
Anyway, it would be trivial to implement yourself - create a class that inherits from LinkLabel, add a string URL property (you may need an attribute to make this show in the designer properties panel if you want to set it that way) and provide an event handler that opens the browser with that URL.
Then you can just add the control in the designer (or at runtime), set the URL property and it will work without having to set event handlers.

Did you use the LinkClicked event instead of OnClick? Then you can use this in the event handler:
(sender as LinkLabel).LinkVisited = true;
System.Diagnostics.Process.Start("http://example.com");
It's not bound a specific browser - opens in the user's default browser. The setup is low - just instantiate the LinkLabel, add an event hookup to LinkClicked (which is one two-line method) and add it to the page. What's unwieldy about this approach?

In the end I used LinkLabel.Links.Add to modify the link destination dynamically..

.Net C# Design View errors

I have subclassed a Treeview and on instantiation it loads a new ImageList (and the associated Images).
Whenever I switch to the designer view, it's also trying to run this code, however the images aren't in the designer's path, so it crashes. I ended up putting in a hack to see if the current directory is "Visual Studio", then do nothing... but that's so ugly.
I find this happening for other things. If a control is trying to use objects during load/initalization that are only available while the program is running, then the Design View cannot bring up the control.
But is there a way to get around this?
I guess what I'm hoping for is having a try/catch for the Designer (only) with the ability to ignore a few errors I know will be happening (like FileNotFoundException, etc.).
Thanks

Everything that inherits from System.Windows.Forms.Control has a DesignMode property that returns a boolean indicating if you are in design mode or not. You could use this to determine when to/when not to load external resources.

Usually it is better to move the loading of these resources to an override of OnLoad as they are rarely required directly at construction. This fixes the issue you are seeing and means that only trees which get displayed at least once will perform these additional resource loading steps.
Otherwise, you can just exclude these steps during design time by checking the DesignMode property and acting accordingly.

This is a fine pattern to use if you're making a control library with a sample of images when shown in the designer or hook ins to other designer features but as a pattern for development I'm not sure it's very effective.
I would suggest shifting your "business logic" (in this case your loading of certain images into a treeview) outside of the bounds of your treeview control. In your case I would place the logic within the Load event of the form that the control is inside:
public void Load(object sender, EventArgs e)
{
string path = "c:\somePath\toAwesome\Images";
myFunkyTreeView.AddImages(path);
}
For larger apps I personally think you want to shift the logic even out of the forms themselves, but this is debatable measure as it requires additional plumbing as a trade-off for the flexibility this provides.

Thanks for pointing me in the right directioon guys.
I had tried registering to the OnLoad event, but that event is triggered when the Design View comes up, so that didn't quite work for me (am I doing something wrong?).
Anyway, I looked a bit more into the DesignMode property. It can only work for Controls, and sometimes your object may not even be a control.
So here's the answer I prefer:
if (LicenseManager.UsageMode == LicenseUsageMode.Designtime) {
// design-time stuff
} else {
// run-time stuff
}
Found it here.