Re: Looking for other controls in design-time - C# Discussion Boards

Looking for other controls in design-time

11-Dec-03 10:31

You could try extending ComboBox, then override WndProc. For the CBN_DROPDOWN notification message (msg id 7), return instead of calling the base.WndProc:

protected override void WndProc(ref Message m)
{
  if (m.Msg == 7) return;
  base.WndProc(ref m);
}

That may stop it, but the documentation for that notification message doesn't mention how to stop it. By not passing the notification message to the ComboBox, though, it shouldn't display the popup window that represents the drop-down. It's worth a shot.

Also, you should consider making your own from scratch. If the above doesn't work, it's often easier making your own controls that trying to change existing ones. Remember that almost every control in System.Windows.Forms is just a wrapper class for their Windows Common Controls equivalent, so the true behavior of the control itself is defined by native code.

If you must make your own, I suggest you download something like .NET Reflector[^] to peer inside how the System.Windows.Forms.ComboBox works for things that aren't apparent in the documentation.

f_popovic11-Dec-03 6:34

11-Dec-03 6:34

Hi! I'm trying to create a control which is inherited from TextBox and will have OtherControls property where programmer in design-time will pick few controls from the same form.
Question #1: How can i access other controls on the form? Or at least what should i change in my solution (read further)?

I tried to implement UITypeEditor for property OtherControls. UITypeEditor should do next:
1) show a form
2) show a list of controls of MyDerivedTextBox type
3) programmer picks few controls & clicks OK
I managed to achieve goals 1 and 3 Big Grin | :-D

, but step 2:

Header of required method in UITypeEditor implementation follows:

public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)

The problem is, sometime it works, sometime it doesn't. And that's because (LIKE MSDN SAYS) we should not rely on ITypeDescriptorContext because it may return null for its Instance property. That way, i cannot access parent form.

For that reason, next code (in previous mentioned EditValue method) fails with message "Object referrence not set to an instance of an object." (both run-time and design-time):

foreach (object o in ITypeDescriptorContext.Instance.Parent.Container)

Is there any solution?
Thanks!

Sorry for such a long post

Filip Popovic

Heath Stewart11-Dec-03 10:23

11-Dec-03 10:23

First of all, you should be checking for null for each property of your ITypeDescriptorContext before your foreach statement, or put the whole thing in a try-catch to avoid unnecessary errors (though throwing exceptions is far less efficient that performing checks).

Second, you can simplify this by letting the ComponentModel handle this itself. If you specify a design-time visible property that is a Type you are interested in, the designer will automatically provide a drop-down for those types (or at least it's documented that way). This only works for components if I remember correctly, though.

f_popovic12-Dec-03 0:17

12-Dec-03 0:17

I've already put foreach statement in try/catch block, but that means that if instance property is null i can't examine controls on the form. Imagine yourself using that control, and hopelessly clicking on property expecting UITypeEditor to show up, but nothing happens. And even if instance is not null at that moment and you manage to pick controls, imagine user's face who is using your program when he sees that program is behaving unexpectedly (or does nothing).

I can't use a property that is of MyControl Type, because that way, programmer would be able to pick just one control. And i need that UITypeEditor because programmer should be able to pick an variable number of controls using single property.

Seems like i didn't write original post clearly. Sorry for my bad english.
Thank You, Stewart.

Heath Stewart12-Dec-03 3:50

12-Dec-03 3:50

How often does this actually happen, though, and under what circumstances? I'm sure there probably are instances where it is null, but the documentation doesn't give specifics. The VS.NET designers probably give consistent input while designing. If you're doing this at run-time, you have to make sure that whatever invokes the UITypeEditor provides a proper ITypeDescriptorContext by implementing and using that implementation when invoking the necessary calls.

There just doesn't really seem like any other way to do what you need. The only way to get the instance of your control (or its container, which the ITypeDescriptorContext also has a property for) in UITypeEditor.EditValue is through the ITypeDescriptorContext (or a TypeConverter for that matter). It's the only thing that ties them together.

If your paranoia is getting the best of you (don't worry, it always gets me too), try to evaluate when the Instance or Container properties are null and either avoid those cases or make sure in your implementation that an implementation of that interface is provided (most likely only possible at run-time, since VS.NET and the built-in .NET designers take care of most of the design-time stuff, allowing you to only be a slave to what it provides).

f_popovic13-Dec-03 23:43

13-Dec-03 23:43

I can't tell when does it happen. I forgot to mention that i was working on control about month or two ago. In my case (with my control and FlashTrackBar from MSDN), i was working for a few days, and then for next few the control didn't work (both design-time and run-time). Sometimes it was changing behaviour even during the use of same instance of VS (same day, of course).

I was really mad about this issue. And disappointed when i saw the explanation in MSDN. After few weeks, i've opened the solution and it just worked. The day after, the same error. And so on, hopelessly.

That means that working on a small project might take years, depending on Framework's will!

Unfortunately, i can see no rule to predict whether Instance is null.

However, seems like i'll have to switch to Delphi, because i've already implemented such control in it. Thank you for you help.
Best wishes,
Filip

Heath Stewart14-Dec-03 5:36

14-Dec-03 5:36

Wait, so you you have a problem with either VS.NET's design-time support or some glitch on your machine and it's the framework's fault? Not hardly. I've written a lot of designer support that's used both in design-time and run-time with no problems - ever! And it works on several hundred machines thus far.

You might try reinstalling VS.NET. Besides, if you're talking about Delphi.NET (Delphi targeting the CLR), then you're still using the framework - it doesn't matter which language you use because it all compiles to IL and uses both the BCL assemblies and any other assemblies you reference. There is no difference, except in a few compiler optimizations for the instructions generated here and there.

So, it's pretty evident that VS.NET is at fault here. Uninstall it, clean up your registry and files, and reinstall it. Something's corrupt.

Or switch do Delphi as you said, but just don't go blaming the framework - even though you're obviously having unfortunate problems - for something that's happening on your machine.

f_popovic14-Dec-03 21:33

14-Dec-03 21:33

Seems like we misunderstood each other. I SAID that JUST controls which use ITypeDescriptorContext.Instance property were behaving badly. NOT ALL CONTROLS. I could still implement designers without problems, but if i wanted to use instance property i would get those messages. Ok?

At that time i was using framework v1.0 and upgraded to v1.1 (if i still remember). Then i had my OS reinstalled (+VS 2003). And i believe that i would still have the same problem, because MSDN still says that there may be some nulls in this interface. Do you suggest me to try again? (now when i reinstalled everything)?

When i blamed Framework, i didn't mean anything bad, it was more like a joke... sounded funny to me at that moment... I'm not a big fan of MS, but i think they did a good job with framework.

No i was not talking about Delphi .NET, because of reason you wrote. I wrote those controls in Delphi 6, so there's no .NET support.

App.Config refresh

RB@Emphasys11-Dec-03 5:10

RB@Emphasys

11-Dec-03 5:10

I am using the app.config for some purposes that it wasn't meant for, or says microsoft, lol. I used a really great example off of code project that allows me to write back to a app.config file while my project is running. My only problem is, it seems that the assembly holds a copy of the file in memory, and when I write back to it, it doesnt reflect the changes when I read from the file again, it shows me the orginial values. Is there a way to refresh the app.config file after writing to it?

Thanks,
Ryan

Re: App.Config refresh

Guillermo Rivero11-Dec-03 7:17

Guillermo Rivero

11-Dec-03 7:17

What I know about the app.config file, is that it loads with the AppDomain.

Take a look in the AppDomain documentation to see if you can reload the config file.

Free your mind...

Re: App.Config refresh

Heath Stewart11-Dec-03 10:15

11-Dec-03 10:15

Once a process is executed in an AppDomain, the configuration information cannot be changed. If you must do this, you must have a process that creates a new AppDomain to run your primary application, which must also exit when the .config file changes. Your host (the launcher) would watch for changes to the .config file and respawn your application after it exits. This is how ASP.NET works, where the host is the ASP.NET worker process (aspnet_wp.exe).

You are right to think that the AppDomain keeps it "cached" (it's actually a one-time read per section, and each section is cached when its read for the first time). The only way to re-read the section is to spawn a new process in a different AppDomain that reads that .config file again.

C# HTTP Text Browser

Guiro11-Dec-03 2:10

Guiro

11-Dec-03 2:10

Hi Everyone...

DOes anyone know how to do a simple HTTP Text Browser? If you do, can you help me out and email it to me no later than Saturday morning to Guiro565@yahoo.com...Thanx Smile | :)

Re: C# HTTP Text Browser

Heath Stewart11-Dec-03 4:15

11-Dec-03 4:15

Slap a multi-line TextBox in a form with an address bar and a couple buttons, then use the HttpWebRequest and HttpWebResponse (or the WebClient) from the System.Net namespace. Enabling hyper-linking would be a little more difficult, but not impossible.

Why not just add a WebBrowser control to a form? There's plenty of documentation here on CP and the rest of the 'net (just google). Just drop the Microsoft WebBrowser ActiveX control on a form. A couple of interop assemblies are generated and you now have your own container for the WebBrowser control, just like Internet Explorer (i.e., iexplore.exe). It takes care of everything itself. You can handle events, implement interfaces (sometimes need to create an interop assembly for some interfaces, or define them manually), and walk / change the DOM (reference the Microsoft.mshtml.dll assembly).

Re: C# HTTP Text Browser

Guiro12-Dec-03 2:57

Guiro

12-Dec-03 2:57

Would you happen to have any source code on the above. It will be greatly appreciated!

Guiro

Re: C# HTTP Text Browser

Heath Stewart12-Dec-03 3:51