snarfblam

The reason you are having this problem is because of the way that the TransparencyKey works. It uses a feature of Windows that allows a region to be specified to customize the shape of the window (make it non-rectangular), but the pixels in a region can only be 100% opaque or 100% transparent. .NET takes pixels that match exactly with the TransparencyKey and exclude them from the region. Suppose you specify Magenta as your BackColor and your TransparencyKey, then you throw a transparent GIF on the form. The transparent pixels in the GIF will be rendered magenta, the BackColor of the form, then these magenta pixels will be excluded from the Form's region because they match the TransparencyKey, effectively rendering the transparent areas of the GIF as transparent. Now suppose we have an ARGB PNG. Suppose a pixel is 50% transparent black. It will be rendered at a 50% average between the form's backcolor and black, which will result in dark magenta. Since this doesn't match the TransparencyKey, instead of rendering transparent or semi-transparent, it will render dark magenta. I don't have the answer to your quesion, only a couple suggestions: It might be possible to create fully alpha-blended windows using layered windows, but I'm not sure. I recommend you research this. I also know that WinAmp features certain "modern skins" that implement fully alpha-blended windows. Perhaps you can figure out how this is done. No matter how you do it, if you do it, you will need to go beyond the functionality provided by .Net. [Edit]I got pretty curious myself, and found this: http://www.thecodeproject.com/cs/media/perpxalpha_sharp.asp[/edit]

The Icon.Save function saves icons in a 4-bit format. Needless to say, this is pretty ugly. Does anyone know a way to save a GDI+ Icon object as a 24/32 bit icon file or a way to save a GDI Icon from a handle to a 24/32 bit icon file?

I am kind of confused by your code. You seem to be comparing char arrays to chars... If I understand what you want to acheive, though, this might help: // You can treat Char values as you would a number. // For example, you can make comparisons like // ('A' > 'Z'), which would result in false, since the Unicode // value of 'A' is less than that of 'Z'. You can also add and // subtract chars' unicode values, which is useful for finding // how far apart two chars are in terms of Unicode values. int GetTheValueThatYouWanted(Char c) { if(c >= '0' && c <= '9') { // If c is in the range of '0' to '9' return (int)c - (int)'0'; // return the value 0 to 9 } else if(c >= 'A' && c <= 'Z') { // If c is in the range of 'A' to 'Z' return (int)c - (int)'A' + 10; // Subtract 'A' to find out how far in the alphabet it is // (A = 0, B = 1...) // Add ten to get range of 10-25 } else if(c >= 'a' && c <= 'z') { return (int)c - (int)'a' + 10; // Same as above, except lowercase } else return 0; }

I would say that the biggest use for XML documentation is the Intellisense. Intellisense is very important in modern programming. There is so much functionality at your fingertips that you can never be expected to learn everything. Intellisense provides a high level of documentation that�s available as you code, saving you the trouble of looking up functions, what they do, what parameters they accept, etc. in reference material. XML documentation is the final touch: the actual descriptions of the code elements, allowing you to key through classes or functions and find what meets your needs or explaining what a specific parameter does. That is one of the things that make programming with the .NET Framework so easy. Using XML code comments is a very easy way to provide this documentation. Additionally, it provides a standard practice for commenting your code as well, explaining what the elements are not only to the programmer who uses your compiled DLL, but your colleague who writes the class with you. I have recently begun using the code comments on everything I code to make sure that everything is well documented, so that a year down the road, I don't look at my own code and end up scratching my head.

No, static does not mean abstract and sealed. I did not say that. What I said is that when compiled to IL, static classes have the sealed and abstract attributes (without any constructor whatsoever defined). Effectively, a class that is sealed and abstract is the same as a class that is static because the only possible meaningful members are static members, so this was chosen as the IL representation of a C# static class. The following is the disassembled IL of a static class: .[color=Blue]class private [u]abstract[/u] auto ansi [u]sealed[/u] beforefieldinit[/color] StaticClass [color=Blue]extends[/color] [color=Green]object[/color] { } And, Mike, you are right. Friend is only the default accessibility modifier of the VB Module. Behaviorally, a VB Module is the same as a C# sealed class, with the exception of the automatic global import. In terms of its IL definition, though, a VB Module is more similar to what you are doing now. It is a sealed class with a private constructor. [Edit]Just an afterthought: One might find it interesting that the rules of the .Net runtime would allow a VB module to instantiate itself. This is only prevented at compile-time by the VB compiler. This is not the case with the C# static (abstract/sealed) class.[/Edit]

The old status bar control doesn't do this. I guess this is just something that you have to deal with when using the status strip control.

You application is using visual styles? Did you make a call to Application.EnableVisualStyles before Application.Run (or did you enable visual styles in the project settings)? Because it certainly looks like they are being rendered with the old 3D graphics. [Edit]I assumed the status strip had an XP look. Never mind.[/edit]

In terms of IL, a static class is declared as both abstract (can not be instantiated) and sealed (can not be derived, preventing any possibility of being instantiated). If you check a static C# class in Reflector, you will see that both these attributes are tagged onto the class. A Module is, on the other hand, defined as internal (Friend) and sealed. I tried declaring a C# class as abtract sealed and tried declaring a VB class as MustInherit NotInheritable and both resulted in a compile time error. I guess you are just out of luck. Microsoft must have just decided that a Module would suffice.

Better get coding. If your needs are that specific, you will probably have a hard time finding exactly what you need in C#. Your best bet might be to find a C++ example and port it, unless you want to write it from scratch.

The method that you are using is actually Windows API, not necessarily VB6, and this feature is not present in the .Net Framework as far as I know, unless you want to set the ControlBox property to false and lose the Maximize, Minimize, and Close buttons as well as the icon.

The Form.Load event is raised after the form is loaded and before the first time that it is shown. At this point it is not visible anyways, and there is a pending call to Show(), meaning that even if you try to hide it, after Form.Load is raised, it is going to be shown. You prevent this only by not calling Show(). If you are using the Application.Run() method, this will automatically call the Form.Show() method on the form passed in. My only recommendation on Cags' code: the code does seem to work, but you might want to consider calling the parameterless overload for Application.Run to start the message loop before you actually introduce the UI. Cags' code will probably work, but I think that my suggestion would be the "kosher" way to do it. I'm not 100% sure, though, so you might want to research it.

The out keyword for C# is just to protect the programmer from himself (not saying that it is a bad thing; we build our programming styles around features like this to build sturdy code): to help him not use an uninitalized variable by explicitly declaring when the variable is intended to be initialized and using compile time errors and warnings to enforce this intent. It is nice to have, but does not effect what happens at runtime. An out parameter and a ref parameter compile to the exact same IL, also the same IL that a ByRef argument compiles to. It breaks down to the fact that this is simply a programming practice that the VB compiler won't enforce for you. Even if you found the appropriate attribute, this is a feature that depends on the C# compiler, and it won't do you any good in VB. If worse comes to worse, you can initialize the variable to a default value to avoid the warning. Just out of curiousity, what sort of code resulted in a compile error about an uninitialized variable? (I couldn't reproduce it.)

Try either setting the SizingGrip property to False or setting the last panel's Spring property to True.

Are you using a ToolBar or a ToolStrip? I don't believe that a ToolBar ever actually receives focus, and a control must have focus to receive keyboard input. If there are controls on the toolbar (and I'm guessing that you have a textbox), you can use the control's keydown/keypress events. If you are using a ToolStrip, and a control within the ToolStrip has focus, the ToolStrip will also receive the keyboard input. Another possibility is to set the containing form's KeyPreview property to true and handle keyboard events for the form.

The .NetFramework 2.0 has a masked textbox control which allows you to set a mask for input. You also need to verify the values entered, making sure that each number is less than 256.

First of all, this is not a limitation of the .Net framework, but a limitation of C#. Visual Basic can do parameterized properties, which are like indexers on steroids, but this was left out of C# intentionally. Why? Let's look at the hypothetical Article class. Needless to say, the Article class represents an article. An article is composed of pages, but it also has attributes that apply to an article as a whole. In the world of programming, these would be represented as properties, such as the TypeOfPaper, Title, and TypeOfBinding properties. Pages are represented by the Page class, but how we deal with the Page objects is a matter for debate. Since C# does not support parametized properties, we could use a function to obtain page objects: the hypothetical GetPage(int pageNumber) function. This representation implies that each page is a separate object relationally dependant upon only the Article class that contains it. While there is nothing really wrong with this, there are other ways of looking at it that Microsoft prefers. In the real world, a group of objects has its own inherent properties, which are separate from the properties of whatever may contain the group. Microsoft has designed C# with the intent that programmers will see groups in this manner. When we apply this concept to our program, we should represent the group of pages itself as a class, which would be the hypothetical PageCollection class. The PageCollection class has a Count property, an Add method to add pages, and a Remove method to remove pages, allowing us to treat not only the Article and each Page as an object, but to also treat the group of Pages as an object. Our Article class not only exposes but internally manages its pages through a PageCollection class. This is just a step towards an object oriented point of view. The entire .Net framework follows this design pattern. When you access the items in a ListBox, you don't write ListBox[3] to get the fourth item. You write ListBox.Items[3]. And the items property returns a collection rather than a single item, so that you can also do things like ListBox.Items.Clear(). If you want to access pages by number, but don't want to treat the pages as a group, I would advise that you simply use the GetPage(int pageIndex) method instead of a property.

The values are generally persisted via the AddRange function for collections, meaning that the property which returns the collection can be (and probably should be) read only. The problem is that there is a lot involved in telling a designer how to serialize data and objects. Have you looked at a tutorial on using designers for collections? You might find these tutorials to be educational. They might not address your question directly, but they should give you insight into the world of .Net designers and help you find a solution. http://www.xtremedotnettalk.com/showthread.php?t=70318 http://www.xtremedotnettalk.com/showthread.php?t=70320

The whole point of indexers is to create classes which behave in the same manner (or very similar) as an array. With this in mind, it doesn't make much sense to create an indexer property for an object that doesn't act like an collection itself, but rather simply contains a collection. I understand that you want to create a property that acts like an array, but using an indexer in that fasion means you lose a whole lot of functionality. When you return an indexed object, you can perform a foreach loop on it (assuming that it is enumerable), you can store a reference to the collection if you need to access it repeatedly, and if the collection programmer so desires, you can modify the collection by adding and removing items and call any other function that the programmer decided to implement. When you use a VB style indexed property, all you get is a property get and a property set.

There is a difference between sharing the fruits of your intellectual labor and advertising, and as long as this is clear, there shouldn't be a problem. Most of the users of this forum are very reasonable. But, for other reasons, I'm not too sure about the showcase thread. If you want to share your work, you can always create a website. They range from free to cheap, and you can throw a link to it in your signature or profile. If you have something particularly useful, it can go in the Code Library, and if you have something to offer that is particularly educational, the Tutor's Corner is a good place for it. Though I admit it is an attractive idea initially, the fact is that there are already lots of websites with tutorial, example and demo projects available, such as Code Project, which pretty much covers all the bases. Besides that, it is a bit outside the scope of these forums.

You could skip the regular expressions and just do what seems to me to be the simplest thing: check for each quality that you want in a password. Check if it is 8 chars long, then check if it contains a number and a non-alphanumeric. Function ValidatePassword(ByVal Password As String) As Boolean If Password.Length < 8 Then Return False 'Too short Dim HasDigit As Boolean = False Dim HasNonAlphaNumeric As Boolean = False For Each c As Char In Password If Char.IsDigit(c) Then HasDigit = True If Not (Char.IsLetterOrDigit(c)) Then _ HasNonAlphaNumeric = True Next Return HasDigit And HasNonAlphaNumeric 'If it has both qualities, return true. 'If not, the password is not strong enough. End Function For a really "strong" password, you could check to make sure that the password is not only eight characters long and has the two special characters, but also that it does not consist of only one normal (i.e. found in a dictionary) word and the special characters. In other words, remove the number and non-alphanumeric character, and compare with a dictionary (or spell checker). If you get a match from a dictionary, or a correctly spelled word from a spell checker, you have a mid-range strength password. If not, you have a very strong password.

This is probably because the drag & drop source is waiting for the drag & drop operation to be completed. By performing a ShowDialog() in the event handler, which doesn't return control to the caller until the form is hidden, you are tying up the thread. Try something like this, which will show the modal dialog in the application's main UI thread: // Invoke function that will show modal form on UI thread private void MyControl_DragDrop(object sender, DragEventArgs e) { this.BeginInvoke(new SimpleVoid(ShowIt)); } delegate void SimpleVoid(); // Delegate type to use with BeginInvoke public void ShowIt() { // function to show modal form on UI thread using(Form1 newform = new Form1()) { newform.ShowDialog(this); } }

Simply place panels in other panels to create more "frames". If you want three tiled vertically, for example, drop the first on the form, set its Dock property to Dock.Top. Drop a second on the form (let's call it Panel2), set its Dock property to Fill. Drop a thrid panel into Panel2, setting its Dock property to Dock.Top, and then another into Panel2, setting it's dock property to Dock.Fill. The form is now split into three panels, and the bottom panel will expand/contract to fill the form.

That would be more thorough, but to be honest, I have never used a non-zero based array in .Net. They don't really make sense and you have to go through extra trouble to create them. As far as my program practices go, I don't way out of the way for error checking because if a particularly unusual object, such as a non-zero based array, makes its way into the code, it isn't what was expected and I would consider it invalid input which should constitute an error. Exceptions are like my way of saying "Hey *******, what kind of array is that?" (Besides, Nerseus said "If it's a regular array.")

The collection is definitely a better idea. You just need to make sure that new forms are added to the collection, otherwise you will run into serious problems when one form spawns another which doesn't end up being closed before the main thread terminates.