Volte

ADO and ADO.NET are both in the "ADO" family, but they are not versions of each other, just as Visual Basic and Visual Basic .NET are almost nothing alike. Plus, since ADO.NET is managed and ADO is not, you should always use ADO.NET over ADO in a .NET application. If you are using unmanaged code, ADO is still a viable choice though.

You have to use SqlConnection to connect to an SQL Server databases, yes. If you need to be able to store a connection from any kind of database, store it in an IDbConnection object, but remember that since IDbConnection is just an interface, it cannot be used by iteslf. It can only be used to hold a database connection object which has been previously defined.

C# does not include a #include directive (no pun intended ;)). You simply have to declare your types and such inside your files.

ADO is not an "older part" of ADO.NET - the only thing the same between ADO.NET and ADO is part of the name.

I'm not even so sure that the .NET progress bar is the real Common Controls one, so the PBS_ styles may not even affect it. You'd probably just be better to write your own from scratch. It's dead easy anyway. A simply percentage calculation and one FillRectangle call should do it. Plus you could customize it however you wanted (add text, gradients, whatever).

DataSet is just one part of ADO.NET. There is much more to ADO.NET than just that. It is certainly much more flexible than ADO. There is really no reason to use ADO over ADO.NET. You just need to learn how to use it. :)

You should just be able to create a class with the Serializable() attribute, and use the XmlSerializer class to automatically serialize/deserialize it to and from disk. That way you don't even need to "read" the key from the file, you can just deserialize the file into the class, and then use the properties of the class to get what you need. As long as you store the printers (in your class) using a collection which is Serializable(), you can add the printers to the collection, and they will be correctly stored and retreived upon (de)serialization. In your case, you would need it to serialize a collection of monitoredPrinter objects, each with a DeviceName property.

It may just be busy. Try putting an Application.DoEvents right after the lstTracks.Items.Add(lstItem)line. Also, I noticed you are using regular ADO - since this is .NET, you may want to consider switching to ADO.NET. Look in your MSDN for tons of information about ADO.NET (System.Data namespace).

This is a project I worked on a few months ago, meant to expand my knowledge of the internals of the way .NET assemblies worked and how to use the System.Reflection namespace to work with them (and it did!), and now I'll release it to you. It is a fair duplication of the Object Browser included within the .NET IDE. I've released it to a small group of users already, but now I'll release it here. I'll warn you right now, the code is by no means squeaky clean. There are some little hacks, messy bits, and there are no comments (at least I don't think there are any :p). However, the overall structure of the application is sound, and can be easily expanded on. I had originally intended on writing a resource viewer part to this too, but I never got around to fully implementing it. Maybe someday. Anyway, please download it, try it, look at the code and get what you can out of it. Report any bugs to me via PM, thanks. objectviewer.zip

Try replacing these three lines:typedef void (* TUpdatePercent)(int); typedef void (* TAddMessage)(LPCSTR); typedef void (* TProcessFinished) (void);with: typedef void (__cdecl * TUpdatePercent)(int); typedef void (__cdecl * TAddMessage)(LPCSTR); typedef void (__cdecl * TProcessFinished) (void);

You will need to extract the data from the Items collection and put it in your own serializable collection, then serialize that. No part of the ListBox is serializable as-is.

If you try to call a __cdecl function with the StdCall convention, it will still work, but the parameters will remain on the stack after the function has completed, meaning your stack space will quickly run out if you need to use the function many times. Perhaps you could show us more code so that we can see what each of your delegates look like and such.

If you derive your own control from ProgressBar, you can override the CreateParams property (i.e. don't set it, but override it) and modify them there.

Also, I believe you need to set the styles in the constructor, not in the Load event.

You can store it into a String, but you need to store the actual RTF codes. Use the .SelectedRTF and .RTF properties of the RTb rather than .SelectedText and .Text properties.

You will more than likely need to design your own editor form to do that. I don't think there's a built in one.

UseDateTimePicker1.Value.ToShortDateString()to return the value selected in the control.

That's not as bad as the initial releases of OfficeXP which could only be installed four times and then they would stop working entirely. :p [edit]Yay, another round number. 1400 posts[/edit]

That may be true, but if anything it indicates that more people know PHP than ASP.NET (less PHP jobs would show that more people are making their own PHP sites). ASP.NET takes skill - a one armed blind monkey can throw together a PHP site in a few days. Still, if you have a choice between PHP and ASP.NET, and the ASP.NET package won't hit you up for too much extra cash, I would definately go with that one. PHP still has its uses though.

If you use DirectCast to cast Sender.Parent to a ContextMenu object, it should work.

In VB.NET it's MyBase.

My recommendation is to allow users to change their resolution, but not to force the change on them. If they are using a higher resolution than the one you force on them, it will not please them, I'm sure.

SQL Server is extremely expensive for even one client license. MySQL is free. For a large site with lots of traffic, sure SQL Server and ASP.NET will win every time, but PHP is sufficient for most sites. Besides, there are many more PHP programmers out there than there are ASP.NET programmers, and I doubt that will change too quickly.

They are just like regular classes, only they can be added to your form, and can interact with other controls on the form. The MSDN would be a good place to look.

They're in the dropdown in .NET too, but for the Form's events you need to select (Base Class Events). Just select the name of the object in the left combobox and choose the event on the right combobox.