Volte

I think the BitBlt way you were using before is probably the simplest and most efficient way.

[api]waveOutSetVolume[/api]

You could eliminate two of those loops by simply filling the whole form with white and then drawing black squares with the loop. It might not affect performance, I don't know, but since it's happening every time the form is drawn, it might.

Do you mean a handler? You can do: AddHandler MyMenu.Click, AddressOf HandlerSubYou can assign as many events to the same sub as you want, as long as they are all the same kind of event.

Breakpoints stop your code from executing at a certain point so you can pinpoint the exact line of code that causes an error. While in break mode, you can press F8 to step through your code one at a time, and you can hover your mouse over a variable in the code window and a tooltip will tell you the value. Very useful for debugging. :)

.. what? What do you mean by a handle? Do you mean adding an item to a menu given its handle?

There is no "problem"; the reason the GDI+ is slower than if you made the program in MFC is because MFC uses native Windows GDI32, rather than .NET's GDI+. Since GDI32 is faster than GDI+ (for simple things, at very least), using P/Invoke to use the GDI32 APIs would be a good solution to speed up drawing. Look at this thread for information about that.

Set the TreeView's "AllowDrop" property to True, and then use the TreeView's "DragDrop" event to capture the dragging and dropping of an object. You can use the "GetNodeAt()" method of the TreeView to find the tree node that is at the point you dropped on. The drop point is stored in the DragEventArgs in the event as e.X and e.Y.

DrawImage does not use BitBlt internally (at least I don't think is does), although it does use the same basic functions that BitBlt does. GDI+ is slower than GDI32 in general, although it is much, much more flexible. If you are doing something as simple as painting an image onto a Form, using GDI32 (e.g. BitBlt) would do fine. You'll need to use P/Invoke to do it. P/Invoke (platform invoke) just means that you can call the unmanaged code in GDI32.DLL from your managed .NET app. There's information on declaring APIs in C# in the MSDN.

I don't understand.. could you attach a small, appropriately sized screenshot of what happens? Do you have any specialized OnPaint overrides, or any style that you are setting to the form (using SetStyle, such as UserPaint)?

If you are using SelectObject() on a DC that you have created yourself that you'll delete at the end of the sub, and don't plan on using the previously selected object any more, it is safe to delete it.DeleteObject(SelectObject(hDc, hGdiObject))

Sounds like the security features of Windows are kicking in... is this an NTFS partition? I think the best way to do it is to simply place your code inside a Try....Catch block and bypass the error. Try 'do your check here Catch e As Exception System.Diagnostics.Debug.WriteLine("Error encountered: " & e.Message) End Try

Which command? There's probably a Windows equivilant.

Heh, OK, I didn't realize you were the one that we'd already had this discussion with. From your code, it didn't look like it was being called that many times. Have you declared vbSrcCopy as anything? If Option Explicit is not on, then that will evaluate to 0. vbSrcCopy is not a constant in .NET.

If you are making a control, just stick with GDI+. GDI32 is faster, but you won't notice it in a control like this (you would only notice it in a graphic intensive application, like a game, and it's possible that in the case of many many calls to the GDI32, GDI+ would end up being faster). Recently there has been a lot of discussion about "Oh, GDI32 is faster than GDI+", but that doesn't mean you should use GDI32 instead of GDI+; GDI+ is a managed part of the .NET Framework that .NET natively supports, while GDI32 requires calls to GDI32.DLL. When I tested it, the speed ratio was about 5:1 - it took about 500ms to draw 2000 images with DrawImage, and about 100ms to draw 2000 images with BitBlt. In that case, it would probably take around 0.25ms to draw with DrawImage and 0.05ms to draw with BitBlt. Not a big deal at all.

ListBoxes don't have multiple columns; what you are doing by asking for 2 columns is making it simple list the data in two columns, and making it scroll left-to-right, like the 'Small Icons' view in Windows Explorer. You will want to research the ListView control if you want to list multiple columns.

I use the upper method for most things, because it allows you to initialize the variable, and use the 'New' keyword to initialize the object.

You need to put all drawing code in your Paint event, otherwise it will simply be painted over as soon as you draw on it. If you want to force the control to redraw itself do this: [i]Control[/i].Invalidate()

Try this instead:c = ColorTranslator.FromWin32(i)

Windows 98 does contain the memory leak. It was fixed in ME, I believe.

Here is a simple example I just whipped up; you'll need to add your own code to only color the ones you want or whatever. Private Sub TabControl1_DrawItem(ByVal sender As Object, ByVal e As System.Windows.Forms.DrawItemEventArgs) Handles TabControl1.DrawItem Dim g As Graphics = e.Graphics Dim textX, textY As Integer Dim textSize As SizeF Dim tabText As String = TabControl1.TabPages(e.Index).Text textSize = g.MeasureString(tabText, TabControl1.Font) textX = e.Bounds.X + (e.Bounds.Width - textSize.ToSize.Width) \ 2 textY = e.Bounds.Y + (e.Bounds.Height - textSize.ToSize.Height) \ 2 g.DrawString(TabControl1.TabPages(e.Index).Text, TabControl1.Font, Brushes.Red, textX, textY) End Sub

You'll need to set the DrawMode property to OwnerDrawFixed and draw the text onto the tabs yourself in the DrawItem event. However, the problem with this method is that bold characters are wider than regular characters, and you can't change the widths of the tabs themselves, so bold text wouldn't fit. You could either append spaces to the Text property of each tab (which would cause the tab to resize itself to fit), or find another way to make the tabs stand out (such as using red font or something).

Simply use the .Hide() method of the main form, rather than .Close(). The app only terminates if the application which was used to start the program (i.e. your main form) is actually destroyed. If you hide it, it just becomes invisible.

This is a .NET forum. You can try asking your question http://www.visualbasicforum.com and someone over there will try and help you.

In the Constructor for the Form, you can do this: Me.SetStyle(ControlStyles.DoubleBuffer, True) Me.SetStyle(ControlStyles.AllPaintingInWmPaint, True) Me.SetStyle(ControlStyles.UserPaint, True)Which causes the drawing of the window to be done entirely by you (except for the border and titlebar), but as long as you do all your drawing code in the Paint event, it should be flickerless. Whenever you want to refresh the window, do Me.Invalidateas it's much faster than Refresh. Also, if speed is not crucial, you might want to look into the GDI+. It's not as fast as standard GDI32 (it's not *slow* by any means, it's just not as fast as GDI32), but it's built for .NET so it's much more flexible and easy to use.