snarfblam

Not very helpful, but this is the best suggestion I can come up with off the top of my head. You could try to find some kind of animation control that can play GIFs or AVIs without visible controls. I believe that the file copy animation is an AVI found in a Windows directory (at least, it was last time I checked, but that was Windows 95).

So, the application opens its own window? When you say "main" window, do you mean that it becomes a parent window, recieves focus, appears on the task bar, becomes topmost ("stay on top")...? I think you need to elaborate a little on what is going on here. The solution probably lies in the realm of threading, app domains, or method of invocation, rather than method of instantiation.

Re: Buttons are not lightweight MrPaul, you are correct that buttons have never been light-weight, but UserControls had the option to be light-weight and it would be much easier to build a button from a UserControl than completely from scratch. I now have to completely handle keystrokes, mouse movements, implement painting behavior, you get the idea, building it all from scratch. A UserControl would do 90% of the work for me. As for your "hybrid" light-weight controls, I've been toying with the idea. It would probably be the best way to do things, but the implementation could get tricky. I think the easiest solution might be to have lightweight controls derive from the Control class so that they can create their own window and be hosted in the designer, but it would require some sleight-of-hand at runtime to either (preferably) prevent the window from being created, or immediately destroy the window. As to the root of my problem, I know that the underlying problem isn't simply that each button has its own window. The problem is DotNets underlying form-rendering engine, which is slow. Using many windows exacerbates the problem to the point of intolerability. Using windowless controls allows me to circumvent DotNet's rendering system and implement my own. And I would like my approach to be clean, polished, functional, and re-usable because I have run into this problem before and I will run into it again. The biggest arguments against windowless controls are that "handles are cheap" and it makes rendering (specifically, z-ordering and overlapping windows) very difficult, but for general use, where windows don't overlap but there might be a very large number of controls, even when controls can render quickly it is still a senseless waste of resources. At the very least, the option to have a window or share a parents window should be build into the fundamental Control class. All that being said, I am still open to other options if they meet my needs.

This might be a stupid question, but if this is a class library, are you sure you have System.Windows.Forms.dll referenced?

I've brought it up in the past, but I feel compelled to make an issue of it again. Windows Forms is sorely lacking what is known in the VB6 world as "light-weight controls," or, controls that don't own their own window, and instead share their parent's window. The reason that I bring this up is because I am writing a program that includes calculator functionality, and am basing my calculator loosely on the Calc.exe program included with Windows. You know the one, with lots and lots of buttons. With only a fraction of my buttons in place, the price I pay for having that many windows becomes abundantly clear. In the ballpark of 25 buttons, with each redraw, I can see each button being drawn as the form takes image painfully slowly. This is on my laptop, and I'm sure that there would be quite a difference on my desktop, but the fact is that my program will be used on, at least, my own laptop if not others. I wrote my own LightweightControl class, which I inherited to create a LightweightButton class. At this point both of the two are very far from finished, but the drawing speed seems to be an order of magnitude faster, and visually indistinguishable. Before I put hours (or, more likely, days) of effort into writing complete light-weight controls (which could never be supported by the designer...) I was wondering if anyone else has run into this type of problem and what other approaches have been taken to solve it.

But I don't like extenders. Don't you remember my long, whiny post about C# 3.0 features?

I could not reproduce the problem. Are you doing any multithreading, control creating, or other such things that can cause IDE problems?

Different attributes are stored in different ways. The filename, creation and modification date are stored in the FAT. Some attributes are file-type specific. Data such as artist and title are stored inside files, either at the beginning or the end, and differently inside different file types. Others are stored in alternate data streams in the file system. Windows just nicely ties them all into a unified interface.

Nerseus, you make a good point with DotNet nullable types. The trick with the Nullable type, however, is that it is a struct, and is never truly a null reference. To achieve this type of functionality in a more general way, it would require wrapping any classes where this behavior is desired in a struct, which brings up another interesting idea. For the incredibly common class, string, it might be reasonable (or, probably not) to write such a struct-based wrapper. // (Incomplete) class that wraps a System.String object and eliminates // the possibility of a null reference. It is implicitly castable to and from // System.String, so it can be used transparently and interchangeably with // System.String objects. struct SillyString { string value; public string Value { get { if (value == null) value = string.Empty; return value; } } public SillyString(string value) { this.value = value; } public static implicit operator string(SillyString value) { if (value.value == null) return string.Empty; else return value.value; } public static implicit operator SillyString(string value) { if (value == null) return new SillyString(string.Empty); else return new SillyString(value); } public static readonly SillyString Empty = string.Empty; public int Length { get { return Value.Length; } } public Char this[int i] { get { return value[i]; } } public SillyString Clone() { return this; } public int CompareTo(string value) { return Value.CompareTo(value); } } The SillyString might be nice, but would probably prove to be superfluous, imposing a performance tax and with only occasional benefit, but to be perfectly honest, I do find myself running into NullReferenceExceptions with strings from time to time, although they are very easy to debug. As for the nullable pattern, it does seem overly elaborate for general use, and I don't see how the pattern could possibly be enforced in C#. Unless I'm missing something, it would require that a programmer make proper use of it, or the null reference exceptions would persist. MrPaul, perhaps the Nullable keyword should be applicable to either a type or a member. You are right in thinking that this is a concept that would generally be applied to a type as a whole, but sometimes it might be more appropriate to apply only to one or two members. The nonull feature would be a nice convenience, but, then, there are lots of prerequisites that it might be nice to enforce using a nifty keyword or syntax, such as non-zero or positive integers, and exclusion of NaN and infinity values for floating point numbers. As for the extended behavior of the break keyword, I personally think that this is something that C# sorely lacks.

This is just a thought I had. I don't expect, or even really hope, that it should happen. Just sharing some thoughts, I suppose. A somewhat novel idea occurred to me. At runtime, the only thing that actually stops the CLR from invoking an instance method on a null reference is a runtime check for a null value. If such a check were removed, we could invoke a non-virtual instance method on a null reference, resulting in a this pointer with a null value. The natural question would be, "What person in their right mind would want to call instance methods on nothing in particular an OOP language?" There are times, however, when this could be handy. Consider a common problem with strings. We might assume a string variable has a value, even if the value is empty. This mistake can result is a null reference exception when we check the length of a string, change its case, or call the instance Equals method. With "nullable" string methods, however, we could write a Length property that looked like this: // nullable keyword to declare intent to allow null references public nullable int Length{ get{ if(this == null) return 0; else return charbuffer.Length; } } The behavior we achieve here is that even if we read the Length property on a null reference, we get the intuitive return value of zero. Of course, this "feature" would not be without drawbacks. We take the non-null value of the this pointer for granted, and especially with unqualified class members, it would be all too easy to add null-reference exceptions to your program instead of reducing them. So, am I the only who cooks up wacky programming features, or does anyone else have anything to add?

Perhaps, maybe, this post on another forum will help you. It explains manipulation of HTML elements via the WebBrowser control. It should bear some relevance to the AxWebBrowser control.

Not having any experience writing tool strip controls, all I can offer is this one idea: You might want to use a tool such as Reflector to examine the ToolStrip controls designed by Microsoft. There may be a combination of attributes required in order for a ToolStripControl to be displayed in the list. For a quick and dirty approach, add a ToolStripButton to the tool strip, and change the control's type in the designer-generated code.

Depending on what you are doing, you might want to use System.IO.Path to extract the containing directory and then System.IO.Directory.Exists (I think such a function exists) to verify that the path exists.

In order for the form to be shown modally, it should be shown via the main thread. If the second thread needs to wait for the form to be closed, it should block until the main thread can signal that the form has been closed. As for the precise mechanics required, you would have to consult some reference, a tutorial, or someone who knows more about multithreading than I.

I recommend you research the AddHandler keyword. It provides a mechanism to dynamically add event handlers. If you are removing controls later on, you should also use the RemoveHandler keyword to remove handlers so that garbage can be properly collected. Here is a quick sample that will handle the click event (I don't know the signature of the hover event and I don't have VB on this machine). Sub IDontKnowWhereThisSuffAllGoes Dim AtomElement As Element() = New Element(118) {} Dim i As Integer = 1 Dim X As Integer = 10 Dim Y As Integer = 8 Dim Xpos() As Byte = {0, 0, 17, 0, 1, 12, 13, 14, 15, 16, 17, 0, 1, 12, 13, 14, 15, 16, 17, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} Dim Ypos() As Decimal = {0, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 8.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5, 9.5} Dim ElementColorIndex() As Byte = {0, 1, 13, 1, 2, 10, 11, 11, 11, 12, 13, 1, 2, 14, 10, 11, 11, 12, 13, 1, 2, 3, 3, 3, 3, 3, 3, 3, 3, 7, 3, 14, 10, 10, 11, 12, 13, 1, 2, 3, 3, 3, 3, 3, 6, 6, 6, 7, 3, 14, 14, 10, 10, 12, 13, 1, 2, 4, 3, 3, 3, 3, 6, 6, 6, 7, 3, 14, 14, 14, 10, 12, 13, 1, 2, 5, 8, 8, 8, 8, 8, 8, 8, 8, 8, 9, 8, 9, 9, 9, 9, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5} Dim ElementColor() As Color = {Color.FromArgb(0, 0, 0), Color.FromArgb(83, 142, 213), Color.FromArgb(149, 179, 215), Color.FromArgb(194, 214, 154), Color.FromArgb(209, 102, 0), Color.FromArgb(237, 215, 121), Color.FromArgb(203, 203, 203), Color.FromArgb(252, 213, 180), Color.FromArgb(215, 228, 188), Color.FromArgb(255, 255, 255), Color.FromArgb(216, 216, 216), Color.FromArgb(117, 146, 60), Color.FromArgb(246, 47, 0), Color.FromArgb(242, 242, 242), Color.FromArgb(165, 165, 165)} For i = 1 To 118 AtomElement(i) = New Element AtomElement(i).Location = New System.Drawing.Point(10 + (Xpos(i) * 45), (60 * Ypos(i))) AtomElement(i).Size = New System.Drawing.Size(46, 61) AtomElement(i).SetAtomNumber(i) AtomElement(i).BackColor = ElementColor(ElementColorIndex(i)) AddHandler AtomElement(i).Click, AddressOf CustomClickHandler Me.Controls.Add(AtomElement(i)) Next End Sub Sub CustomClickHandler(sender As Object, e As EventArgs MessageBox.Show("Holy Macaroni!") End Sub Note lines 20 and 26-28.

I'm having a hard time understanding what's going on here. The topic refers to DLL dependancies. Are the two different classes in the same assembly? Also, it sounds like using an interface or base class for the "Tire" class could simplify things here.

Re: regedt32 and regedit I see. I guess System32 isn't included in my PATH. And, indeed, it does show up in Task Manager as regedit rather than regedt32.

Re: VB "features" Quite a common complaint. This is why we always tell new programmers to remove all references to Microsoft.VisualBasic and Microsoft.VisualBasic.Compatability. The biggest problem is that these don't come excluded in new projects by default and Microsoft does very little to encourage programmers to migrate new the "DotNet" method of doing things.

Re: PATH environment variable I've never even heard of regedt32, unless that is simply a misspelling. There are two programs, regedit and regsvr32, that are often confused with eachother. regedit is a Windows registry browser/editor/patcher tool and regsvr32 is probably what you are after, as said by MrPaul.

It should be as simple as setting the TabControl.SelectedTabPage to the newly created tab page. Could we see the problematic code?

Like I said, it was a guess. Just curious, does the designer re-generate the placeholder when the file is re-opened?

Re: VB "features" Well, now that we are off topic, it is easy to say that Microsoft should have had the cojones to do away with VB6 legacy functions, controls, and features that might be redundant or "encourage bad programming." It's a whole different story when you are trying to sell Visual Basic. For businesses, it is not acceptable to have to re-write entire applications. This "backwards compatability" sometimes brings porting programs into the realm of possibility. I agree whole-heartedly with your recommendation to stay away from VisualBasic namespaces, but for pre-existing code there is a need for compatability and Microsoft had to try to fulfill this need in order to make the purchase more worthwhile for more customers.

I would say that that particular error is the consequence of the difference between an object oriented approach and a non-OOP approach. I whipped up a quick app... [Color=Blue]Private Sub[/Color] Form1_Load([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]System.Object, [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.EventArgs) [Color=Blue]Handles [/Color][Color=Blue]MyBase[/Color].Load [Color=Blue]For [/Color]i [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To [/Color]255 TextBox1.AppendText((Chr(i) + i.ToString() + Chr(i)).Trim() + Environment.NewLine) TextBox2.AppendText(Trim(Chr(i) + i.ToString() + Chr(i)) + Environment.NewLine) [Color=Blue] Next End Sub[/Color] [/Code] It seems the DotNet String.Trim() function trims [i]all whitespace[/i], while the legacy Trim() function trims only spaces.

Just venturing a guess, here, but judging by the name designerPlaceholderDeclaration, I would say that this is a place holder to support the designer. I don't know if there is any more signifigance to it, because I don't program with ASP.NET, but I would guess its just there to help the designer sort things out (which is why it woudn't make a difference if it is excluded in the end product).

Off the top of my head, the GC and Process classes might help.