mocella

Like Optikal said - it looks like you're pulling the majority of this table (or have a known subset of data you wish to update). Why not create a stored procedure that can pass arguments in to update the necessary columns with the info? I'm assuming you're just updating them all in a similar fashion. This way, you're saving a ton of overhead by just keeping the work on the database side and not passing it over the network back and forth.

Depending on how you load up/bind your combobox, you could do a check like: if( cboSomeCombo.SelectedIndex == -1 ) { //do your "nothing was selected" logic here } else { //continue your "good" logic, something was selected }

Oh, at the top of your class, add: using System.Configuration; I thought I added that in my last post, sorry.

This book is pretty solid on the various concepts for SQL Server 2K: http://www.bookpool.com/.x/pfe3z4604m/sm/0764543792 Not sure how specific it gets on Triggers, but I can check for you if you want. (my copy is at home, not work)

Try something like this: string appDir = ConfigurationSettings.AppSettings.Get( "ApplicationDir" ); string updDir = ConfigurationSettings.AppSettings.Get( "UpdateDir" ); string saveLocation = appDir + updDir + fn;

You could use an output parameter to hold this value, or use exec_scalar and use a return in your proc. Of course, I'm assuming you're doing SQL2K when I suggest these options. Either would work.

Have you looked into the Application Updater blocks from Microsoft? It uses the BITS service to get code to the end-user as new updates are published in some predetermined location. Basically - you do your install package once, then the app pulls the new code to the client as it's available. This may get you around the issues you're having. On issue you may have is if your clients are on XP SP2, there's some changes to how BITS works - so you may have to look into that. We're on Win2K, so the blocks worked fine for us.

I think if you initialize your string value(s) to your "Data Not Found" message prior to the loop you should be set. It's been a while since I used a datareader, but I think if you have any empty result-set the loop won't even run once, since it's top-checked.

You should look into the application blocks for Configuration Management that Microsoft published a while back - here Even if you don't want to add all this into your project, you can see how they handled writing information back to XML config files and update that code as you see fit.

georgepatotk - I don't envy the position you're in :eek: Okay, so a bit of a background on Nant. Basically, the idea of it is to give you, the developer/architect/admin/whatever a scripted environment which you configure via XML config files (much like app or web.configs in VS.net). It does stuff like get latest code from VSS, command-line compiles for C# and VB.net (even vb6 and C++) code, allows you to move stuff around (xcopy), zip files, run executables, pretty much anything you can think of. So it's pretty powerful, yet fairly simple to get up and running. Here's a link to a sample config file for Nant that runs a hello-world compile The great thing with Nant from an integrator or architect point of view is that you can control what can compile - so no developers can just add project references to "this really cool 3rd party control that I wanted to use" (but you may not own/need, etc) - the build script is totally independent of your sln and project files for .net. You can create a Nant script at any time in your project timeline, but backing in with NUnit and unit-tests mid-project may be a little tough (both selling to management the time you need and getting your code to a test-able state). Nunit is a framework for writing code-tests as a developer. The idea is you write a test, then write the code to support it. Think of it like writing a USE case, then writing all the code you need to make that USE case happen (it's similar to this). NUnit can be found here If you want more help with this, shoot me an PM and we can take this discussion offline and get into specifics for your project's needs. ;)

Or like PlausiblyDamp hinted at - Refactoring. Check out Martin Fowler's book on the subject - it's got a lot of good ideas as well as samples on how you go about refactoring out problems with your(or others') code. I've had a lot of luck using the test first approach to develop (TDD) over the past year or so. So, not only is all my code supported with unit tests, my functions hardly ever reach more that 10-15 lines of code. This kind of ties in with the refactoring topic - get it to work, then break down to the lowest units of work and these all become their own functions. To ThePentiumGuy - we've all been there when trying to clean up (not change, just sort of organize :cool: )one thing and all the sudden nothing works. My solution to this is frequent check-ins as you successfully fix each issue you're working on (unless your environment doesn't allow for this in which case I'd load CVS on my own machine to version the stuff locally at minimum).

You could probably combine the last two queries via the UNION operator for sure. One thing - what kind of database are you using? If it's sql-server, you could probably just write a stored proc to process all the logic in one call to the server. I'm still tired so can't think about the rest of your code yet. Sorry

You can attach an event-handler to your applacation thread like this - this piece goes somewhere really early in the app code - like the Main() or constructor of your first window: //global try/catch handler to catch any unhandled exceptions anywhere in app Application.ThreadException += new System.Threading.ThreadExceptionEventHandler( this.GlobalExceptionTrap ); then the function looks like this: public void GlobalExceptionTrap( Object sender , System.Threading.ThreadExceptionEventArgs e ) { //call error routine to write error to event-log or database, etc: LogError( e.Exception ); } ...edit.. Oh, and you asked how to kill the app - that's done like this: public void LogError( Exception currentException ) { //do your logic to log the error (or whatever) ...... //Close the application Process.GetCurrentProcess().Kill(); }

We've had pretty good luck with just creating a solution in VS.net, then adding it to VSS, then start adding the projects for each layer/tier of your application. So yeah, it's one central VSS repository that all the developers point to for the latest code/check-ins. In our case, there were about 12 developers working on the various pieces of the different projects at any given time and we didn't really run into much module contention (and in VS2005 this will be even lessened with Partial-classes!). If you're on a larger team, you can look into "Branching/merging" in VSS so each developer ends up working in their own little sandbox copy of the code, then mergers their stuff back up to the master - but I've seen plenty of problems with that approach (bad merges, etc). One thing I'd really recommend is creating a build script with Nant which you can use to ensure that everything people are doing is playing nice with the rest of the latest code. So there, you'd have a developer make some changes, get latest (minus their work-in-progress files), and run the Nant script to ensure everything is still working. Unit-tests with NUnit might also be helpful if you're into that method of development.

Pass your form instance as a parameter to IRCEngine.Connect, and set that your global "MainForm" equal to this passed param - now you should have addressibility back to your actual form instance. I'm assuming you're calling into IRCEngine from the current instance of frmMain.

Oh yeah, when you instantiate your child forms, for this to work, you need to pass a reference of the mdiParent down to the child and set that as the mdiParent in your child classes in the constructors. Then, when you need to open the other windows, you'll have to do something like: mdiParentType tempParent = (mdiParentType)this.mdiParent; tempParent.OpenOtherChild(); Hope that helps.

Did you include the merge-module for the Ultragrid (assuming there is one) in your setup package? This is where I'd start looking.

(assuming SQL2K here): You'll have to have your stored procedure query text (the actual SELECT statement) as a VarChar field in which you append the table name from your param passed into the proc. Once you have the string build, you can EXEC that: EXEC( @yourVarCharQueryStringGoesHere ) On a side note, this isn't really improving efficiency as far as sql performance as this will "compile" every time you run this proc, but it will increase maintenance efficiency for your developer/dba teams. To each, his own though. ;)

You could expose public methods in the mdiParent that are used to open your child forms. Then, from child A, issue a call into the mdiParent to open child B. In child A, you'll probably have to cast "this.mdiParent" to a variable of type-of your actual mdiParent class (we'll call it "Daddy") - then call DaddyInstance.OpenChildB(), or whatever.

Post your build script so someone here can take a look at it. I assume by "skip" that you get no errors when you run Nant?

Check out MSDN on "Regex.Replace()". Looks like their sample does a reimplementation of ToUpper(), but you can slightly modify that code in CapText() to return an empty string.

Check out the Nant task reference here: http://nant.sourceforge.net/help/tasks/index.html Also, the Nant Contrib stuff may be of interest to you: http://nantcontrib.sourceforge.net/help/tasks/index.html

Why not have an array of your controls? So if you're working with textboxes, you'd do: friend myTextboxes() as Textbox = new Textbox(42) then have some startup code that assigns your textboxes into this array - myTextboxes(0) = txtSometext1 ... myTextboxes(41) = txtSometext42 There's other approaches you can take here, but if you're set on an array of controls, this should work.

Also, here's a cleaned-up build file: <?xml version="1.0"?> <project name="Hello World" default="run"> <property name="debug" value="true"/> <target name="clean" description="remove all generated files"> <delete file="HelloWorld.exe" failonerror="false" /> <delete file="HelloWorld.pdb" failonerror="false" /> </target> <target name="build" description="compiles the source code" depends="clean"> <cl outputdir="D:\Cpp Test\" options="/clr"> <sources> <include name="HelloWorld.cpp" /> </sources> </cl> </target> <target name="run" depends="build"> <exec program="HelloWorld.exe" /> </target> </project>

Well, I did some digging, and I'm by no means a VC++, so this is totally specualation, but here's the compile script generate in VS2003 with a simple HelloWorld console app - somehow, you'll need to make this into NANT tasks/options. This is from BuildLog.htm which VS2003 generates when you compile a C++ project: Creating temporary file "d:\Cpp Test\HelloWorld\Debug\RSP000001.rsp" with contents [ /Od /AI "D:\Cpp Test\HelloWorld\Debug" /D "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yu"stdafx.h" /Fp"Debug/HelloWorld.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" ".\AssemblyInfo.cpp" ".\HelloWorld.cpp" ] Creating command line "cl.exe @"d:\Cpp Test\HelloWorld\Debug\RSP000001.rsp" /nologo" Creating temporary file "d:\Cpp Test\HelloWorld\Debug\RSP000002.rsp" with contents [ /Od /AI "D:\Cpp Test\HelloWorld\Debug" /D "WIN32" /D "_DEBUG" /D "_MBCS" /FD /EHsc /MTd /GS /Yc"stdafx.h" /Fp"Debug/HelloWorld.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Zi /clr /TP /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\mscorlib.dll" /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.dll" /FU "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\System.Data.dll" ".\stdafx.cpp" ] Creating command line "cl.exe @"d:\Cpp Test\HelloWorld\Debug\RSP000002.rsp" /nologo" Creating command line "rc.exe /fo"Debug/app.res" ".\app.rc"" Creating temporary file "d:\Cpp Test\HelloWorld\Debug\RSP000003.rsp" with contents [ /OUT:"D:\Cpp Test\HelloWorld\Debug\HelloWorld.exe" /INCREMENTAL /NOLOGO /DEBUG /ASSEMBLYDEBUG /PDB:"D:\Cpp Test\HelloWorld\Debug/HelloWorld.pdb" /FIXED:No kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".\Debug\HelloWorld.obj" ".\Debug\AssemblyInfo.obj" ".\Debug\stdafx.obj" ".\Debug\app.res" ] Creating command line "link.exe @"d:\Cpp Test\HelloWorld\Debug\RSP000003.rsp""