Nerseus

Well if you showed everything exactly as you have it, then the line: Environment.SpecialFolder.Desktop is returning the string "0". Can you create a simple Console app and see what the line "Environment.SpecialFolder.Desktop" shows? Maybe it needs a ToString() or something similar on the end (to get the path as a string)? -Nerseus

I don't think you're going to find a book like what you describe. You've listed a WIDE array of topics. Here's how books are *normally* laid out: 1. C++ syntax (just C++ the language) 2. Managed C++ (generally info about the framework and how to use it with C++) 3. General purpose .NET books (database access, internet connections, etc.) Beware books (or look for them!) with "Visual C++ .NET" in the title. Many of them are about using Visual Studio and it's many wizards and give little info on coding. They generally have an appendix for a "quick start" to learning C++. If you really want to use C++ (managed or not doesn't matter), then pick up a good C++ book first and foremost. You can't do much with a language if you don't know it's rules. I have this book and would HIGHLY recommend it. Bjarne Stroustrup's book is also very good (he's the creator of C++, more or less), but I liked the other book's style better. To learn ".NET C++" is really to learn the .NET framework. There are a number of good books on the subject. I'd figure out what areas you really want to learn and get a book that covers most of them. For example, ADO.NET could cover 2 or 3 large books by itself. But if you just want an intro, then it might be covered in a chapter or two by some books. MFC is old school - don't worry about it too much. It's Microsoft's Foundation Classes, a C++ specific library of code similar to the .NET framework. COM is just a standard - kinda hard to describe by itself. It, too, has become old school with the introduction of .NET. It was made popular by VB4 through VB6. You would create a DLL as a "COM" DLL, which exposed a standard set of methods so that programs using your DLL could "see" the classes, methods, etc. in the DLL. Before COM you had plain vanilla C-style DLLs which meant you declared your functions "by hand". If you ever used VB's feature of calling into the Win API then you used a C-style DLL. .NET provides a much easier and robust way to figure out what a DLL has inside (including classes and methods, interfaces, etc.). You can create a COM DLL from .NET and you can use COM DLLs from within .NET. But unless you've got existing code already compiled as a COM DLL you probably won't care one iota about COM. -nerseus

Whoops - thought you were looking for a way to display your collection in a "grid-like" control for editing, not for the collection type itself. If this is truly for a Control, divil probably has a good suggestion. If it's for a class, you might just go with implementing ISerializable (if my spelling is right) to have the class read/write it's own properties. If this is a generic collection (name/value pairs) then why care about the order of the properties? If you really care, I'd suggest creating a small struct or class to hold the name/value pair and something like an ArrayList to store them all. But I'm not really sure what you're doing with these values - hard to guess at how to implement it :) -nerseus

I'm not sure why you're disposing the TextBox... But, you shouldn't normally have to remove a binding. Normally your code should bind controls when the form loads (or before) and never again. Or, bind controls per Tab, if you use a TabControl. It sounds like you may be using some common code in a Module to create and manage controls. Without knowing how/when your code is being called, it's impossible to guess when the binding would work - from my point of view. I AM glad you got it working though :) -Nerseus

The code in your "new" button is hard to understand, but I don't see you defaulting the date to today - you only do that in the Save. Normally you add a row to the DataTable directly, not through a control. I would expect something like the following which creates a new row, defaults the datecolumn to today, and then adds the row to the DataSet (NewRow just creates a DataRow - you have to use Rows.Add to get it in the dataset): void btnNew_Click(object sender, System.EventArgs e) { try { DataRow newRow = dsAB1.Tables["tablename"].NewRow(); newRow["datecolumn"] = DateTime.Now; dsAB1.Tables["tablename"].Rows.Add(newRow); } catch (System.Exception exception) { MessageBox.Show("Error: " + exception.Message); } } In the above, datecolumn is the date I assume you have bound to the DateTimePicker? Also, in your save, the following will never hit: if(this.dsAB1.Tables["pratilacDijete"].Rows[col-1]["datum"]==null) this.dsAB1.Tables["pratilacDijete"].Rows[col-1]["datum"]=DateTime.Now; A column won't be "null". You'll want to check for System.DBNull.Value: if(this.dsAB1.Tables["pratilacDijete"].Rows[col-1]["datum"]==System.DBNull.Value) this.dsAB1.Tables["pratilacDijete"].Rows[col-1]["datum"]=DateTime.Now; While you could set this date in the Save, it's generally better to set it in the "new" if you can. Actually, if this date is ALWAYS going to be the current date/time then you'd set it in the stored procedure, if that functionality exists in your database. That way it gets the server's date/time and can't be "fudged" by a user's computer clock. I assume you don't want it to ALWAYS be today, otherwise you wouldn't be offering the user a chance to change it via a DateTimePicker. -nerseus

When you say you "repeat the databind" command, can I assume you are clearing the old databinding first? Does your Position code look something like: Me.BindingContext(custDataTable).Position = Me.BindingContext(custDataTable).Position + 1 If all this fails, I'll try to duplicate it here. -Nerseus

I'd hope you'd only have to close the form, rebuild your project/solution, and reopen the form. At the worst, maybe close the whole solution and reopen it. If you copy and paste controls to a new form, you risk losing "custom" properties that are saved in the resx file (pictures get saved there along with a lot of custom control properties). -nerseus

I can't help with what you want, exactly... I would guess you'd want to use Reflection to get the various properties exposed in your object, assuming you have them in a strongly typed collection class and not a generic collection. I can suggest that you might want to use the built-in PropertyGrid control. It is the control you use in Visual Studio to change properties at Design time. It can be used on your own objects at runtime as well. -Nerseus

First, are you sure you have more than one row? Maybe we can see your code for binding and for changing the position. You must make sure that whatever you supply as the DataSource to the textbox's binding is the EXACT same as the one used on Me.BindingContext(...). It won't work if they're "the same" but coded differently. For example, you can bind a textbox to the exact same thing, two different ways (assume a variable ds as a DataSet was defined earlier): textBox1.DataBindings.Add("Text", ds, "Table1.Column1") textBox1.DataBindings.Add("Text", ds.Tables("Table1"), "Column1") Although they point to the exact same data in the exact same dataset, the binding context is setup differently. If you bound the textbox the first way and tried moving position on the form using the following, it wouldn't work: textBox1.DataBindings.Add("Text", ds, "Table1.Column1") Me.BindingContext(ds.Tables("Table1")).Position = Me.BindingContext(ds.Tables("Table1")).Position + 1 In the same above, you'd have to use the BindingContext as: textBox1.DataBindings.Add("Text", ds, "Table1.Column1") Me.BindingContext(ds.Tables("Table1")).Position = Me.BindingContext(ds).Position + 1 Of course, are you sure you've got the textbox bound correctly? Is it showing some data from your DataSet, just won't move off the first row? -Nerseus

Did you read my message at all? Your behavior would be expected since your DataSet has a NULL value in it. It doesn't matter that the DateTimePicker shows a date - it's not in the DataSet. Re-read my message about setting the DataSet's value and all should be good. -Nerseus

If I remember correctly, a DateTimePicker can't show a "NULL" value. Meaning, the picker won't show up "blank". It sounds like your DataSet has a NULL value in the column, its default. The DateTimePicker is showing Today's date as it CAN'T show a NULL. Even though it shows Today's date, the DataSet isn't in sync with the DateTimePicker. If you set the DataSet's value to Today's date as mentioned above (or some other default) the DateTimePicker will be in sync with the DataSet. -nerseus

We use a similar approach, but there are no command line args. Instead, an XML config file is delivered with the "loader" application. The "loader" reads the XML file to figure out where to find the latest EXE (in fact, what the EXE's name is and more). If the config isn't found, a "default" server can be searched for the config file. So if compiled with the right "default" server, you could conceivably only deliver the EXE. In practice, our "deployment" requires both the EXE and config file. Want to talk cool? Have the "loader" detect updates and update itself (new default server, new config files, etc.). -nerseus

Did you mean to have a SUM() around the QtyOrdered field? You didn't show it in your first post. If you don't, then you don't need the group by. If you DID want the sum, then try this (you can change it back to a string, but make sure the query runs fine by itself first) Select tblSalesOrderDetails.ItemID, IsNull(SUM(tblSalesOrderDetails.QtyOrdered), 0) AS [QtyOrdered] FROM tblSalesOrderDetails WHERE tblSalesOrderDetails.LineStatus = 'Closed' GROUP BY tblSalesOrderDetails.ItemID I added an alias on the IsNull(SUM...) otherwise that column won't have a name. I gave it the same name as the column, though you may want to change that. The major change above from the other suggestion is that I didn't use the IIF() -- just the IsNull. IsNull should take two params: If the first is NOT null it returns that value otherwise it returns the second value. If that format isn't supported, try COALESCE -nerseus

You can also go through the form, which has a BindingContext for all controls. For example, to move to the next row for all bound controls: Me.BindingContext(esTableName).Position = Me.BindingContext(esTableName).Position + 1 -nerseus

The "standard" install of SQL Server (with the standard formats of English) expects dates in the Month/Day/Year format. You can format your DateTime variable that way, if you like. A SqlParameter would also work though it appears you had problems and went with another solution :) If you want to format a .NET DateTime variable, try something like: dim st as string = "update UserInfo set DateLastOn= '" + objlaston.ToString("MM/dd/yyyy") + "'" You'll note I removed the convert date/time as that would happen automatically in the sample above. -nerseus

As a guess, are you defaulting the DateTimePicker control's value or the DataSet's value? If you're "defaulting" your new row with something like: dateTimePicker1.Text = DateTime.Now.ToString(); If that's what you're doing then don't.... When working with bound controls, you should always set default values through the DataSet and let the bound control update itself. You'd want something like this instead: ds.Tables[0].Rows[0]["dateColumn"] = DateTime.Now; -Nerseus

As a side note, it's generally considered a horribly bad idea to exit a function that expects a return type and NOT return that type. C# won't let you, VB let's you slide by, apparently (I wonder if there's an option to force you to explicity return something). As a less interesting side note, you can also return "string.Empty" rather than "". -nerseus

Use the SortedList class, no need to make your own. -Nerseus

Can you use IsNull on the Compute method? Something like: ...Compute("IsNull(sum(Quantity), 0)", ... I can't remember. If there's no built-in way, then I'd suggest a function. -Ner

Did the Listbox's Sorted property do what you want?

What is dvFrAddr? It "looks" like a DataView, but you're not binding to it... Why not just use the listbox's Sorted property? -Nerseus

I think the argument can be summed up with this statement, from MS: When I want to maintain something, I want simplicity. I don't care about saving 2 nanoseconds on an event. Generally speaking, whatever code is running in the event is going to be significantly longer than the time it takes to get into the function/method. I'll agree that delegates are a bit weird (a new Type and they have global scope) and confuse most people at first. Truth is, most Windows programmers won't use them except as event handlers for their controls. If you invest some time in learning "true" OO programming, you will find many more uses for them - they form the basis for notification between components. As the recent "Design Patterns in C#" book mentions, you can use interfaces to accomplish the same thing, but delegates make the code "cleaner" - that is, easier to view and understand. -nerseus

If it were me, I'd load the DataSet with the full schema (using your first XML snippet that contains everything - or as much as you can get into one XML file). Save the DataSet using WriteXml with a second param of XmlWriteMode.WriteSchema. You can then create your dataset from the saved schema. When you want to load XML into the DataSet, use ReadXml and specify XmlReadMode.IgnoreSchema. -Nerseus

The Technical Release version of Whidbey is available to MSDN Universal subscribers, I believe. There may be other options - that's how I got it. Yukon is the name of the next SQL Server and it supports writing procs in C#, though I've heard pros/cons about flexibility vs. performance (C# stored procs being slow). Haven't played with Longhorn yet. To finish the triage, Longhorn is the next version of Windows. There's also Avalon and a few other codenames for upcoming releases of MS products. There is, in fact, a codename for the version of Visual Studio that comes out AFTER Whidbey (which is due in 2005). How would you feel to be on a team developing Whidbey, the next "big thing" and before it's even released you're already outdated? :) -Nerseus

In many regards, yes - VB's intellisense is better. You can "workaround" C#'s lack by using Ctrl-Space to show Intellisense in many situations. Whidbey (next version of Visual Studio) has corrected this for C# with a LOT more intellisense including the ability for VS to learn your "favorites". It's cool. -Nerseus