Nerseus

I think you'll need to create an appropriately sized Bitmap object and use the Graphics object's DrawImage method to draw the image to the Bitmap. Then use the Bitmap's Save method to write it out. It can write to various formats using the ImageFormat param (I think). -Nerseus

There are a couple of ways to get what you want. You could run a query to do the filtering in a WHERE clause. You could also use the DataTable's Select method, which returns an array of DataRow objects which you could loop through and add items to the Listbox. Or, you could create a DataView with a filter and bind the ListBox to the DataView. Deciding on an option depends on where you want to filter (in the database or in C#/VB code), how often you want to filter (performance considerations), and whether you're already bringing down the whole table that will be filtered or not. -Nerseus

The easiest way is through a Forms BindingContext property. If you've bound your textbox like so: // Text is the property on the TextBox control // FirstName is a column in the DataTable Table1 textBox1.DataBindings.Add("Text", myDataSet.Tables["Table1"], "FirstName"); Then you can navigate forward/backwards like so: this.BindingContext[myDataSet.Tables["Table1"]].Position++; You can also create your own CurrencyManager, as Robby suggested. Especially if you need multiple "pointers" into the same DataTable. -Nerseus

I'm not sure what you need exactly. If you already have everything you need saved to Access, converting to an All-XML solutions is super-simple. Make sure you write out and read the XmlSchema information (a parameter on the WriteXml and ReadXml methods). As for serializing classes, I'm not sure what your goal is. Do the classes hold data not in the DataSet? How do you save the class's data now? -N

Try switching from Debug to Release, then back to Debug. In Form_Load put the following: Debug.WriteLine("Hello World") When running, open the Output window (ctrl-alt-o) and see if you see the words "Hello World". If not, you're probably not really in Debug mode. -Nerseus

Ah, well then - if you control the collections, I think you'll have to manually add a new field to the "parent" object type. So if the Order object currently has a field MemberID, add a field called MemberName and manually fill it. Then hide the MemberID column in the grid. The other solution, which might be better if you have a lot of tables with these foreign key relationships, would be to buy or create a custom control that can bind to the ID and display the text from another table. This is usually a combobox of some kind. Here's are some links to look at: Link 1 Link 2 They have code you can use to create your own ComboBox control that fits in a grid. -Ner

Try this: Dim b As Bitmap = New Bitmap("lookout.jpg") Dim newBitmap As Bitmap = b.Clone(); PictureBox1.Picture = newBitmap I haven't tested this... :) -Nerseus

Well first, I'd probably rather use XML to store this kind of thing. But, I'd probably not even put the blank lines in my array. I'd first change the top bit of code to the following: Dim sLine As String Do While objSR1.Peek <> -1 sLine = objSR1.ReadLine If sLine.Length > 0 Then If Open2 Is Nothing Then oldSize1 = -1 Else oldSize1 = UBound(Open2) End If ReDim Preserve Open2(oldSize1 + 1) Open2(oldSize1 + 1) = objSR1.ReadLine End If Loop -Nerseus

Can you post the whole project as a zip file? It would be a lot easier to see the problem that way. Make sure you only zip the root folder, don't include the bin folder (no executables in the zip, please). -Nerseus

I'm not sure what you mean - what are you trying to do? Every form contains a collection of the bound controls and datasources so that you can easily navigate through a DataSet (for instance), with the usual Next/Prev buttons. -Nerseus

If you can do it in either, I'd use managed C++. Or, are you asking *how* to do it in either managed or unmanaged? -Ner

Also, VB6 never had a Copy Project option. If you use the menu "Copy Project As" you're only copying the project file, not the individual source files. If you change any of the forms or BAS files in one project, they'd be updated in the other as well. In VB6 you had to actually copy the folder contents as well. In .NET you only need to copy the root folder (and subfolders only if you've created them in your project). You don't need the bin folder (unless you've MANUALLY copied files in there, such as pictures to be loaded at runtime). You also don't need the .user files or any sourcesafe files. -Nerseus

I don't know of any easy way to do it, but I've heard of this project that purports to interfacing with all instant messengers. You may be able to delve into the code to see what's going on - a completely non-trivial task I'm afraid. An cheap alternative might be to find the AIM process using the Win32 API and check it's running time. That won't show you connected time, just how long the program itself has been running. I don't really know the APIs for that but good luck :) -Ner

Try something like this: Dim vbill As Single = 20 Dim vPtip As Single = 0.15 TextBox1.Text = String.Format("A {0} tip on {1} is {2}", vPtip.ToString("0.00%"), vbill.ToString("c"), (vPtip * vbill).ToString("c")) -Nerseus

XML is an option. If you plan on storing the data in a DataSet, use the DataSet's WriteXml and ReadXml methods - easy as pie. You can even start with your Access database, save the data once to XML and never use Access again. -Nerseus

I should have asked - are you using custom collection objects to bind to your DataGrid or a DataSet? If a DataSet, how are you creating and filling it? If it's something else, I'll need to see the code. If you are using a DataSet and want to start, just add a new column to your table. For example: DataColumn c = dataset1.Tables["Table1"].Columns.Add("MemberName", typeof(string), "Child(OrderMember.MemberName)"); I don't know what you relationship or column names are, so I faked them above. -Ner

Well C++ is probably the only language where the API IS the framework. Should have mentioned that language specifically since this is a .NET forum :p (this assumes non-managed C++ -- managed C++ won't use the API any more than C# or VB.NET, from what I understand.) Having said that, you can't really do much in C++ without knowing the API so its pretty obvious which one you'll want to learn first. But, you should still learn the datastructures, good coding techniques, etc. next (before you become an expert in the API) since, as I said, good programming is good programming regardless of language, OS, platform, etc. -Nerseus

I would use a DataReader for this, if you really need to know the IDs in your client application. You'll definitely want to use one SQL statement (a Query in Access or a Stored Proc in SQL Server) to handle both the UPDATE and SELECT, as you'll want to guarantee that you get a unique value. Generally, you don't really need these IDs until you're ready to save, not just when the user clicks a new "New Row" button. It's generally better to not increment your identity values until you actually do an insert. That means you may not even need a class to handle getting an ID - instead, the proc that's going to do an INSERT using a Master or TempID will do the necessary SQL code to UPDATE the master ID table and get the current value. -Nerseus

Go to your Project's properties (right click the project) and look at the Common Properties, General. There a section for "Output Filename". If you read the description you'll see that you have to change the project Assembly Name property. You can change it in the same dialog. -Ner

I'd pretty much always trap for Exception if there's even a remote chance something unhandled may occur. But don't let general-purpose error handling be an excuse for bad programming. Writing good, clean, solid code requires a lot of work and lots of "If" logic to test for things manually first, as Derek suggests. It's much easier to test for an error-like condition and alert the user (or take appropriate action) than it is to do something generic in an error handler. For instance, something as simple as running a query and getting out a value is a lot more than checking the SqlException in case there's a Database error (fairly rare, in my experiences, though timeouts could be common in a dev environment). For instance, after excecuting DataAdapter.Fill, you should check the Rows.Count property of the table to make sure you got back a row before referencing Rows[0]. Then you need to check the column for null before blindly converting to a string. You may be thinking, "this is an insert, if it doesn't throw an SQL Exception, then it will work" but that might not be true. Who knows what might cause the insert to not return a value. Maybe a DBA changes the default "No Count" option on the database and you're suddenly getting two recordsets back. Not handling Exception means you'll get a nasty default MessageBox and the dreaded NullReferenceException. I'd vote for always trapping potential errors with specific types and also always trap for the Exception. I would use try/catch wherever there's a remote chance your code might error out. If you have a simple routine, such as: // private int counter = 0; declared at the top of the form private void button1_Click(object sender, System.EventArgs e) { counter++; } I would not put any error handling on that. Granted, if the user presses the button over 2.5 billion times, you might get an overflow. But I'll take that chance :) -Nerseus

I'd learn DataStructures first for sure. I'm not sure I'd worry about the Linked Lists and such, since they're a little different in .NET. In C/C++ where you had pointers, you had more control to create these specialized types of objects. In .NET it's much simpler, in that you can create an object with a reference to itself, to keep track of your list. Or, you can use built-in collection objects for many simple collection types (Stack, Queue, Hashtable, etc.). The API is good to know as well, but it's generally for when you need to do something specific that .NET doesn't expose for you. So just learning the Win32 API might be fun but you won't need many of them. There might be some benefit to knowing what it has available in case you want to take advantage of it when an otherwise unsolvable problem comes up. But, I think you'd get a much greater benefit as a programmer/developer learning the core coding techniques. Besides data structure, learning good .NET structured programming is good to know, too. Meaning, when to create classes, methods, properties, etc. is important and can't readily be taught by books or school. Before learning the API, I'd learn about the .NET framework (all the built-in classes). I've only had to use the API 2 times so far in the past year - a couple of calls to do some subclassing (to intercept all user input to handle auto-timeouts) and a few to find a message box window handle to shut it down (when an app times out and I want to kill a user's session to force them to log back in). Those cases are rare and I couldn't tell you without looking them up again what the calls are or how they work. The point being that the API is useful, but you probably won't remember the exactp API calls very often. Good programming lasts forever, regardless of language or platform. -Nerseus

By itself, it looks fine. Is there anything in the Form's Load event that might be causing it? -Nerseus

Slightly off-topic: ...Or petition your state government to do away with that crazy daylight "savings" time. Arizona and Indiana were smart enough to get rid of it and I LOVE it (used to live where it changed, and I hated resetting clocks and figuring out the TV Guide). -Nerseus

I'm guessing that assigning Nothing (or null in C#) might be worse than using String.Empty. If you assign Nothing then check the Text property you'll see it's actually String.Empty. In the following sample, you'll see it prints out Empty. It's just a guess, but I'm thinking there might be a conversion of null to an empty string going on internally. Then again, it may be the exact same thing (hard to tell and I'm too lazy to try and figure out how to see what behind-the-scenes calls are made): TextBox1.Text = Nothing If TextBox1.Text Is Nothing Then Debug.WriteLine("Nothing") Else If TextBox1.Text = String.Empty Then Debug.WriteLine("Empty") End If Plus, in my opinion, I'd rather always keep strings (even empty ones) in a Text property. Putting in Nothing might be confusing later. If you assume that the Text property could actually be Nothing, then you'd always have to do TWO checks to see if anything were in a TextBox: one to check for nothing, one to check for empty string. -Nerseus

I'd hate to use a timer since the timer may not be long enough or may be too long. You can show a form that's not a child and not make it modal. You'll want to set some properties on your splash form, though, to keep it on top so that it doesn't get hidden. Just playing around, I tried the following settings for the splash form and they worked quite well: ControlBox = false FormBorderStyle = FixedToolWindow TopMost = true Caption = - well, no caption - just clear the text When you want to show the form, just create a new instance and call .Show(). You can often do this in the constructor of a large form that you're loading and then close the splash form when the main form (or report form) is activated. -Nerseus