snarfblam

To answer your question simply, DiverDan, because I don't want to. But seriously, there is a more mature, realistic answer too. First of all I want my program to look professional, as well as consistent with the OS and other applications. Secondly I prefer the full functionality of a wholly separate window, which can be dragged outside the bounds of the MDI window, has built in draggability and resizability, etc. Your suggestion is a good one, and a method I have used in the past. It even has some useful advantages over my technique (such as easy dockability), however for this specific application, I prefer an actual separate Form. I appreciate the suggestion, though. And Hamburger1984, I have considered using the method in your HidingToolwindows project, but decided against it only for the reason that in some rare cases it may not necessarily behave as expected. It is probably 99.99% reliable, but there is no substitution for 100%. As I was writing this reply, however, I got an idea which I tried and seems to work. I had previously checked the shared property ActiveForm on the frmMain.Deactivate event, which returned frmMain, the main form which has just lost focus. This serves no use in determining if my app has focus. I added an Application.DoEvents and then checked ActiveForm, and it returned the window that was receiving focus. If ActiveForm returns nothing after a DoEvents, as far as I can see this will properly indicate that my application has lost focus under any circumstances (but I will need to check on the Deactivate event of all non-MDI child, not just frmMain). And BAM! Photoshop style tool windows (actually, photoshop tool windows work a little differently. Mine act more like Word toolbars). Thanks for the suggestions though, they were both good ones.

There is a certain functionality that I am trying to emulate from the tool windows in Photoshop or floating toolbars in Microsoft Word. These tool windows are topmost so that when focus moves to the main MDI window the tool window is not hidden behind it. When the application loses focus, however, (even if the main MDI window is still visible) the topmost toolbars are hidden so that they stay out of the way of other applications. So... I need to detect when my application loses focus. The application class has no "LostFocus" event. I can't use the frmMain.Deactive event because this event fires before the Toolwindow.Active event. Effectively, there is an instant when none of my forms have focus and using the Deactivate and Activate events to determine when my application has focus based on whether or not any of my windows has focus won't work. I need another means of detecting that my application has lost focus or a reliable solution that works around the "focus gap" caused by the fact that the Deactivate event is raised before the next Activate event.

This is information pertaining to my origional question... According to the Visual Basic Language Reference... Also... If you are looking for memory efficiency, based on what I found I would not recommend the Boolean data type, but rather use the individual bits of an integer.

My IDE has been exhibiting strange behavior lately. First I noticed that the text editor wasn't keeping my tabs correctly; when I moved the cursor off a line (this is in VB) where I changed the tabbing of comments or lines of code that used a line continuation the editor would change or revert the tabbing and sometimes even change the tabbing of other lines. Also, the form designer has not been working correctly; when I change the name of a control it would sometimes change the declaration but not any assignments in the generated code. Look: (I changed ComboBox1 to cboType and ComboBox2 to cbtType2. The declaration changed, but the assignments didn't)... Friend WithEvents cboType As System.Windows.Forms.ComboBox Friend WithEvents cboType2 As System.Windows.Forms.ComboBox <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent() Dim resources As System.Resources.ResourceManager = New System.Resources.ResourceManager(GetType(Form1)) Me.ComboBox1 = New System.Windows.Forms.ComboBox Me.ComboBox2 = New System.Windows.Forms.ComboBox 'And so on ...and when this happens, I lose the outlining in the text error, get designer errors and, of course, compiler errors. I checked all of my text editor and tabbing options and they are all as should be (not that any setting should cause this behavior). So my question would simply be: What on earth is wrong with my IDE? edit: Also, My IDE has always done this: Frequently, when I use the "Edit Names" feature, change the names, and disable "Edit Names" the names are not changed in the code and next time I enable "Edit Names" all the names I changed have reverted.

To quote the help files included with studio.net: "Class Enum is derived from class ValueType; that is, Enum is itself a reference type, not a value type." Is this saying that instances of enumerations are reference types... meaning that they come from the heap instead of living in the stack and that they have more overhead? I was always under the impression that an enumeration was ultimately treated as it's underlying intrinsic data type and therefore a value type. I hope I am misreading this sentance and that I am not wrong.

First of all, no, the number of booleans wont actually be 32. It will be 1024 booleans (most likely). And in comparison to the 128 bytes of booleans that would be the 8 (or 12, im not sure) bytes of overhead data isn't incredibly signifigant, so im not worried about that. These are not flags and even if using the flagged attribute is more memory efficient I doubt it would be worth the trouble; I am using the array of booleans as just that and picking the right flag from the enumeration would introduce unneccesary switches or ifs. It would be easier (at least in my opinion) just to use int32s and to check a bit just use the bit shift operator (i.e. 1 << bit_number) and AND that value with the integer. Anyways, thanks for the suggestions.

Suppose I create a boolean array with 32 elements ("New Boolean(31) {}" in vb), will this take up four bytes for the array elements or are the boolean elements not guarenteed to take up only a single bit?

By they are all the same, do you mean they are equally fast? because i am making a somewhat cpu demanding game and every cpu cycle counts.

Is there any difference in speed or overhead between function (or sub) calls and property (set and get) calls in .NET? Or are they essentially the same?

I don't understand what you mean... of course all controls are objects. Everything in .NET derives from the object class. What does that have to do containing other controls?

Surprised indeed. This is contrary to the behavior I expected after reading about container controls in msdn.

In VB6, picture boxes could contain other controls. In .NET, the picturebox can not. Only container controls and scrollable controls can contain other controls (for example, panels and group boxes)

When the background of a label is set to transparent, the labels CONTAINER is drawn behind the transparent label, but no other controls. If you can see through the label to the form, perhaps the label isnt INSIDE the panel, NOT ON TOP. If this is the case then the form will be drawn through the label, but not the panel (it will look like the label cuts a hole in the panel). You DO NOT need to draw the text manually (everyone seems to think otherwise). You just need to make sure that the control is actually inside what you want to show through the transparent control. If what you want to appear behind the transparent label is not a control container (and a panel IS a control container) and you can't substitute a control container control for what you are using, then in that case, YES, you do need to do it manually with the Graphics class.

This is how transparent controls are drawn. First their container is drawn in their rectangle, and then the control (in your case your label) is drawn on top. NO CONTROLS IN BETWEEN ARE DRAWN in that rectangle. For instance: if you have a Form than contains a PictureBox and a transparent label on top of the PictureBox then when the label is drawn, first it draws the forms background in the label's window, and then the label itself on top, but not the Picturebox in between. The appearance is almost as though you cut a hole throught the picturebox straight to the form. In otherwords, placing transparent controls on top of other controls does not produce the exected effect. Transparent controls only work properly when drawn directly over the container (i.e. your form). SO, if you are using a picture box to draw your form's background, your transparent label will cut a hole throught the picture to the empty underlying form, probably giving the appearance of a label that isnt transparent at all. If you are using a picture box, a transparent label on top wont work. You need to set your image to the form's .BackgroundImage property, and the label's background color to Color.Transparent. I tried this and it works as expected. An alternative (if you dont want the image tiled all across your form) is to use a panel control, setting the panel's .BackgroundImage property to your image and place the label INSIDE the panel so that the panel (with your image on it) is drawn behind your label, instead of the blank form. However, if you are showing your image via the Form.BackgroundImage property and the label's .Backcolor propert is set to Color.Transparent, and you still have an opaque rectangle around the label, I don't know what to tell you, because I just tried and it worked. In VB6, the labels were what are known as "Windowless Controls". As the name implies, they down have their own window. Their text was drawn directly on top of whatever is underneath them. In .NET, everything gets it's own window, which makes transparency much more complicated.

Wow. A very straightforward and helpful answer. I'm surprised. Thank you very much, PlausiblyDamp.

Come on guys. I asked if there was a difference between a Do While...Loop and a While...While End, not Do Loops and While Loops in general. All this i know: You can have a Do While... Loop, a Do Until...Loop, Do...Loop While and Do...Loop Until. While... End While appears to be identical to Do While... Loop, which is why I question it's being. What I dont know: Is there ANY difference programatically, in compilation, or any other kind of difference between a Do While...Loop and a While...While End?

This is something ive been wondering a very long time (perhaps years) but have never investigated. Is there ANY difference programatically, in compilation, or any other kind of difference between a Do While...Loop and a While...While End?

The reason for that is probably that this is a declaration for VB6. When declaring Windows API functions, you should always be careful that you are using the right data types. If the declaration is written for VB6, you must change longs to ints!

Hey, guess what I just found! The BitConverter class.

I am making a program that deals with information in bytes. The majority of data is stored in byte arrays, and written to and read from files from byte arrays. Some of this data is Int16s, Int32s, Int64s, singles, and doubles. I need to also store these in and retrieve these from my byte arrays. That means I need the actual binary representations of the values these variables will contain. Were I programming in C++, I could use a union with a byte[2] and Int16, a byte[4] and and Int32, etc. VB lacks such incredibly nifty tools, however, and I must use another means of retrieving the binary data within these variables. I can create functions to do this for me with integers, however at a performance cost. I am not interested in attempting to do this with floating point variables. THE QUESTION: Is there a way in VB to convert, say, a single into a byte[4]? Or a way to write a single into a byte array? Or any other process not overly complex to get the binary data from any of these simple data types? The only solution that has occurred to me so far is to write the single to a binary access file and read it back as a byte array. This entails more complexity and performance cost than I hope my ultimate solution to have, but illustrates the desired effect. Any suggestions will be greatly appreciated.

I am making a program which uses Windows Xp styles. It uses a TabControl to manage documents (similar to the .net studio tabbed interface). The TabControl places a TabPage control inside the TabContol. The default back color of a TabPage is the system Control color. However, with windows Xp styles, the background of a TabControl is ControlLightLight, and under windows classic style the background of a TabControl is Control. How would I go about making the tabpage's backcolor the approprite color? (I am thinking detect if Xp styles are enabled, and setting the backcolor accordingly, but I'm hoping that there is something simpler).

Does this have any signifigant cost on resources?

Thanks a bunch fartnocker. I was aware of that bug. I was not aware of a workaround, though. I tried it and it solved my problem. One more time, many thanks to fartnocker.

I found myself curious all of a sudden about windowless controls. Does VS.NET support any kind of windowless controls as vb6 does? and do windowless controls (i.e. lightweight controls) use any signifigant amount less resources. Many programs (specifically internet explorer) do not use windows for the controls. They are all windowless. Kazaa has radio buttons which have no windows, but are still drawn with windows xp styles. With vb.net thought, all of my controls have a window, and I cant find any relevant properties to change this.

I have a book about directx 9 for vb (".NETY Game Programming with DirectX 9.0") published by Apress. It is very thourough and goes through not only directx but other game programming concepts too. It seems like a pretty good book for a beginner if you have $50 to spare.