Denaes

Sorry, I tried your project and couldn't get it to run. Just something about the way you attached the MDB and ran it through SQL Express. Not something I was familiar with and even when I tried to attach it to SQL Server directly and use a new connection string, exceptions would still be thrown when running the app. But I did take a look and I wasn't familiar with using a TableAdapter as you did on the form (I use them in a public method in the dataset), but your dataset was strongly typed and looked fine. I'm glad you found out what the problem was... well you didn't really find out what the problem was, but I'm glad you found an alternate way of getting it done :)

Hmm, I'll have to look into that aspect. I was digging around for a common interface, but no dice. The Textbox inherits from the TextboxBase which has these behaviors for the EditMenu, but the other controls that act like a TextBox have their own different Base, so Component is the only thing they have in common. You'd think there would be an easier way to implement a windows standard, like it would be considered in the .Net development with the option of going your own way if you wanted to. Sort of like how the context popup works for the Textbox, exactly as you would expect with no fuss. Thank you, I'll look into that tomorrow. I was also thinking that if we'd taken my advice from the design phase and immediately made a custom control extending each control, we could add interfaces and custom code as needed without having to gut forms replacing controls.

You can zip it up and post it here with the paperclip button to the right of the Fonts on the a postings formatting bar. You can email it to me at SlinkingFerret at gmail dot com also. Just make sure to remove the .exe files from all the directories

I know sometimes you have to redo databinding at various points to get a combobox to recognize a change... but if the DataTable isn't finding all the new rows, thats annoying. If it's a smallish sample project, you could post it and I could poke around a little. I know it sounds like the database table you're using seems really simple.

When the form loads you're using the same Fill method with the same SQL? I'm running out of ideas

I'm not entirely sure why a select would work once and not a second time. You've tried to clear the table. The only thing I can think is that a Try Statement might be holding back the insert. Maybe if you tried a fill after the whole Try statement it might act differently. Sounds similar to a transaction about how not everything is fully commited to a DB until after a transaction is ended.

Insert is a property you set in design view in the properties window easily. I'm not entirely sure how you would go about doing it via code

Okay, so the Fill Method isn't working properly. It's running as you can see a refresh in the combobox and it passes that line of code, but it's not selecting all the rows. Whats your Select SQL for that Table Adapter?

If you put a breakpoint on the Fill method, it's definately getting run? Prior to Fill being run, check the Table "transaction_descriptions.rows.count" and then check it after the fill to see if it actually added the extra row. You can use Debug.Print or a messagebox to easily check the # of rows before and after.

You can't use the Update method of a TableAdaptor without an appropriate command assigned to it. If you use a typed dataset, this is all handled for you in the TableAdapter already as an InsertCommand, SelectCommand, DeleteCommand and UpdateCommand. You assign a SQL Statement or Stored Procedure to each of these to perform the appropriate action when you select Update on your TableAdapter. The code you provided didn't refresh the combo because you didn't requery the database after your insert. You have the correct code commented out: 'Me.taTransactiondescriptions.Fill(Me.MB2007DataSet.transaction_descriptions) Without creating an object on your own as you just did, the TableAdapter doesn't know how to do anything. When you provided it with the changes, it found a row to insert, but no command to tell it how to actually perform the Insert. Try your code with the command object with the Table Fill uncommented out. That should work.

Okay, it sounds like it found a row to insert and wasn't able to insert because the command was there in the TableAdapter. Look on the TableAdapter, under the Property called "Insert" with a plus next to it. Click the plus to expand the options. What values do you have for "CommandText" and "CommandType"?

Try this: Me.taTransactiondescriptions.Update(Me.MB2007DataSet.transaction_descriptions.GetChanges()) This is telling it to update the changes as they're found. What code do you have for your insert property on the table adapter? Is it hooked up to a Stored Procedure or SQL?

Just made me question how much I could help if you were using DataAdapters (and VS 2003). No biggie. Did you check to see if the code I suggested was any help?

When you go into your dataset and select the adapter for the table, on the properties window is it referred to as a DataAdapter or TableAdapter? If it's a SAMS book, it might be 2005 with a TableAdapter and they were just updating it from 2003 with the DataAdapter and kept the old naming convention. Or better yet, go to the Help Menu and "About Visual Studio" to make sure it's 2005. If it's 2005, the code I have should work. If it doesn't, it might be a problem with the SQL or SP or something else with a relationship causing an error. I tend to think database side, because you have a try block and that should let you know if there is a problem. The database wouldn't let you know unless you're using SP's and explicitly raise an error of sorts.

Okay, using da (data adapter) instead of ta (table adapter), I assume you're using 2003 and not 2005? You're saving changes to your dataset, but they're not being persisted to the database. If you were using stored procedures, I'd say to put some logic in there to see what's happening. It also might be your SP code. Or your SQL if you're not using SP's. I'm using 2005 and this is how I successfully perform a persist: ' Deleting taOverrideReason.Update(OverrideReason.Select("", "", DataViewRowState.Deleted)) ' Modifying taOverrideReason.Update(OverrideReason.Select("", "", DataViewRowState.ModifiedCurrent)) ' Adding taOverrideReason.Update(OverrideReason.Select("", "", DataViewRowState.Added)) At least in 2005, we're commiting just the changes. You could also just do a .Update(OverrideReason.GetChanges()), but we found the need to differentiate between Add/Update/Delete for when we have to update many related tables. I can't recall doing this in 2003, it's been a while and I don't have any sample code handy so I'm not sure if it was handled differently.

Note: This is a repost of something I posted on the sister forums that hasn't gotten any replys. What I'm looking for is a more simple way to Enable/Disable Edit Menu Items based on Active Control behavior. Behavior (basically, I might miss something): Copy/Cut/Delete - Only enabled when text is selected (SelectedText.Length is the way I normally go about it) Paste - Only enabled if text is on the clipboard I'm handling the event of the Edit Menu Dropdown and I can check the active control (Me.ActiveControl). Now I hope I'm missing something, but it seems I would have to do a Select (or If...Then) to find out what Type the ActiveControl is and then write code Enable/Disable these MenuItems for each type of control. I can do that, but I was hoping there was an easier way to handle this more generically that I'm missing. Any ideas?

oh yeah, about 450mb!

http://msdn.microsoft.com/vstudio/support/vs2005sp1/default.aspx MS has done an awful promotion of it. It's not on my Visual Studio startup screen or on the Visual Studio webpage. You think they'd want to milk the publicity for freely fixing and making their product better. ::shrugs:: I saw mention of the beta from MS and I've been waiting for the non-beta. I finally found word in an employees blog and some news sites.

I just had an Edit & Continugasm!!! I had to turn it off because it caused errors on my computer and crashed VS2005 like 50 times a day. So I just installed the SP1 and it seems to be working. I don't have to stop my app to change a simple setting or comment out a line of code!!! Oh, did I mention that I was happy? :D :D :D

Easiest way is to pass it over in the constructor. On Form2 in the constructor, have a paramater for a form and pass that reference to a private variable on Form2. From there you can set the text using that primary variable because it has a reference to Form1. On Form1, when you create the new instance, pass a reference of itself (this) to Form2 in it's constructor.

Hmm, I was thinking of triggering a boolean on in in/out which would negate calculations on a Form MouseDown Event, but if the Forms MouseDown event isn't happening, then that doesn't help any. Right now I'm neck deep in refining some custom controls, so I can't really play around with the code and test things out, but those were my ideas.

This isn't a C# problem, but a .Net problem. Same will happen in vb.Net if you did this. You're can't access a non-static/non-shared variable/property from a static(C#)/shared(VB) function. If you need to change something in that instance of the form, you're going to need to pass a reference of Form1 to Form2 and set the property on that reference. Or possibly raise an event on Form2 that Form1 can handle, which might be "better", but is a little more complicated.

Hmm, then I'd say you would have to do a form mousedown event (or maybe a mouseover/mousein event for the textbox) and calculate if you're in the boundries of the textbox.

Actually I think the biggest or most jarring change from VB to C# was the way C# handles strings as regular expressions. If you're using 2005, you're gold. If you're using 2002/2003, prepare for a ton of compiler "quirks" that you're not used to with VB. You fix one error and 50 more pop up. Then you fix another and you're down to 20 errors. Then you fix 2 errors and nothing changes. Then you recompile the app and you have 3 errors left. C# 2005 is amazing. They really listened and got a lot of helpful UI fixes. Improved intellisense, error tracking & bracket highlighting. Just talking about it makes me want to use C# again, but I'm in a vb.net project :P

check to see if the procedure is firing. Generally you only want to do something on a mouseup if you want to give someone a way out. like "oh, I didn't mean to click that button, I'll keep the mouse pressed down and move it off the button" You want this to happen on the textbox mouse down event it seems. Check that the procedure is firing and your tooltip isn't stealing/preventing it from firing.