divil

Another, possibly better way: Form myForm = (Form)System.Reflection.Assembly.GetExecutingAssembly().CreateInstance("YourNamespace.Form2"); myForm.Show(); This question has been asked on the forum before.

System.IO.Directory.CreateDirectory()

Simply changing "Module" to "Class" and adding the "Shared" modifier on the default Sub Main is all you need to do in that case.

Use System.IO.Path.GetFilename(strFullPath) to get just the filename from a fully-qualified path.

This sounds like homework to me, and we don't do homework. You should make an attempt at a solution yourself, and if you run in to a specific problem, then we can help.

Yes, that does. Modules are bad OOP design and should never have been included in VB.NET. There is no need for them. Any miscellaneous functions should be grouped together as static (shared) members of a class.

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=69197&highlight=studio+directx That thread has what you need.

In your first form, when you create the instance of the options form. I suggest you go and read about constructors in the help system.

A quick Google search yielded two promising results: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvssamp/html/vbcs_usingthecomportinvbnet.asp http://msdn.microsoft.com/msdnmag/issues/02/10/NETSerialComm/default.aspx

Because on this line: dim mainform as new frmmain You are creating a new instance of your main form. You don't want to do this, you want to refer to the instance which is already there. There are many ways to do this, the most common of which is to pass it in the constructor of your options form: Dim f As New frmOptions(Me) Then your options form can retain that object to refer to the already open form.

They're not, really. The same will happen if you use two Internet Explorer windows normally. It's because the windows share the same cookies, so as far as hotmail is concerned you are logged in from any internet explorer window you use.

You _never_ need to use modules. Your Sub Main can go in any class you like, as long as you make sure it has the Shared modifier in its declaration. Also, please don't include binaries in attachments.

Do you have VS.NET standard edition? If so, I hear that simply can't create class libraries (dlls).

There's nothing wrong with using e.Graphics to draw directly. If you declare another variable and assign that to it, you're using exactly the same object.

This sounds like a bad idea to me - why would you hardcode those? The whole point of DNS is that it should be automatic, traversing a tree to get the desired result, as Derek said.

The best way is probably to make your procedure accept a Nodes collection as one of the parameters. Then you create all the nodes at that level from the database, adding each to the nodes collection passed to the procedure then recursing, passing the Node.Nodes collection of that node. A little wordy, but I think that's what you're trying to do.

Firstly, stop using modules, modules are bad! Secondly, I'm still not entirely clear what it is you're trying to do. I suspect it's much easier than doing what you've been trying, though. Can you explain the problem entirely from the top?

Also, go in to your project properties and turn on Option Strict. You are assigning a string directly to an integer, which is horrible. You should use Integer.Parse or the equivalent instead. [edit]Yeah, that's what I meant[/edit]

Use AddHandler. AddHandler oBrowseForm.myControl.myEvent, AddressOf myProcedure

If you're using the msflexgrid (not advisable as it's not a .net component) you'll have to distribute that and register it along with your application.

Cordbg is the command-line debugger, which you could certainly use if you wished, the GUI one is much easier though. To start the cordbg debugger on your application: C:\>cordbg.exe myapp.exe As soon as it launches the process it'll break execution for you to set breakpoints etc, but just enter the character "c" and press enter and your app will run. When an exception is hit, the command-line app will break again and show you the location in source (assuming you've copied all the source across).

ImageLists are meant to store lots of icons that will perform the same function - for instance, you'd fill an imagelist and associate it with a toolbar if you wanted a store of images for that use. Keys were omitted because they are not necessary for this - designers show a dropdown menu of images to choose from. If you are using an ImageList as a general repository for images in your application, you might consider embedding them all as resources in your app instead. As I said, ImageLists are meant to store a group of similar images, keys would be a waste. That said, you could always use a dictionary object like a Hashtable to build a relationship of strings to images at runtime, you'd have to create a procedure and hardcode the relationships yourself.

If you're compiling your app to MSIL then you will need the framework to run the app, yes.

It sounds like it's either a missing dependancy issue, or just a piece of code using a class that isn't supported on Windows 98 (not all of them are). I suggest installing the Framework SDK on the target machine and using the graphical debugger included with it, it's the same debugger that VS.NET uses so it shouldn't prove too difficult.

To this, you first create your source icon, I assume using the stream returned by GetManifestResourceStream. I take it you're doing this already. You then use the following to extract the different sized icons from it: iconLarge = New Icon(iconSource, New Size(32, 32)) iconSmall = New Icon(iconSource, New Size(16, 16)) iconLarge = new Icon(iconSource, new Size(32, 32)); iconSmall = new Icon(iconSource, new Size(16, 16));