Nerseus

I believe you've got your Boolean and Integer swapped. Try this: Dim MyInt As Integer Dim MyRes As Boolean = Integer.TryParse(NumericUpDown1.Value, MyInt) If MyInt < 1 Or MyInt > 65535 Then MsgBox("invalid number") End If The second param to TryParse is the parsed integer value. The return of the function is true/false on whether the parsing worked. Also, it looks like you want to parse a short integer. Maybe replace Integer with UShort above. Then you'd only have to check against 0 (if that's an invalid value for you). Just an observation, not critical to your question. -ner

Try this: Private Sub Timer_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer.Tick Dim temp As Integer = 0 If Integer.TryParse(FourthLabel.Text, temp) Then FourthLabel.Text = temp - 1 End If End Sub You can add an "else" if you want to handle the case when the label's text is not numeric. -ner

I generally wouldn't worry about performance between if and case, unless your app really needs that level of tweaking. For me, I rarely need a switch unless I've got some kind of factory method that's making decisions. Two other thoughts: 1. Switch statements might be a bad smell (from refactoring) if you have duplicated switches in code. 2. See Code Complete 2's Checklist Since CC2 doesn't provide a clear "which to use and when" guide, I'm guessing the choice to if or case falls into one of two categories: first, decide if there's a reason to NOT use one or the other (the checklist should help) and then just go by personal/professional opinion. -ner

We've recently brought up this discussion at my work, but we haven't gotten past initial testing of multiple instances. The main difference is that you have multiple "servers", each can be configured independentently. Each named instance can be separate from the others. For example, SQL batch jobs are stored at a server level, not database level. That means each named instance gets their own set of batch jobs. We're looking into named instances for our DEV enviornments to solve an issue with names of databases. We have one SQL box for development of many implementations (some live in production, some under development). We use one DB server now with the default instance and we have to rename each DB with a code word. So for project1 we might have Project1_Customer, Project1_Admin, Project1_Common, etc. (those are DB names). For another project we'd have Project2_Customer, etc. What we're looking into now is performance. It's only DEV, but we don't want performance to drop where dev's can't work. With multiple instances, you get multiple instances of... well, something - we're not sure what just yet :) Maybe multiple instances of the "engine" and "services", but to what point they duplicate and what point they share common code that serves all instances, I have no idea. For us, moving to local DB development would be the best option. We're looking into the new TFS suite for DBs and it seems to fit nicely in our flow - only the cost per dev is an issue. Local DB development might alleviate some of this, although we may still need named instances locally. Luckily performance wouldn't impact us there since a local DEV would only be using one at a time. On a production server - I can't come up with a good reason to use named instances right now. Production is usually something you don't want to mess with, and you wouldn't want to have two servers running on the same machine. The DB box is usually the biggest in the network, for production, and we generally spend more time optimizing the DB code, indexes, and such more than anything else. I'd be afraid to throw in named instances in that situation unless I was starting with a problem that named instances would seem to solve. I can't think of any offhand. -ner

You can set the MDI form's KeyPreview property to true, then handle the KeyDown event. For example: private void MDIForm_KeyDown(object sender, KeyEventArgs e) { string s = string.Empty; if (e.Shift) s+= " SHIFT "; if (e.Control) s += " CONTROL "; if (e.Alt) s += " ALT "; s += e.KeyCode; Debug.WriteLine(s); } -ner

I've never tried it, but codeproject has two resources that explain how to hook into the COM library to do this. It looks fairly straightforward. I know it would be better to post code here, but I'd be ripping off the author's work and don't have time to research myself. Hopefully this will help: How to Unzip files using built in shell: http://www.codeproject.com/csharp/decompresswinshellapics.asp How to zip files using built in shell: http://www.codeproject.com/csharp/compresswithwinshellapics.asp -ner

Include the dataAccess folder in your project (did that already, I think). Go to the properties (in Visual Studio) for the file database.mdb and change the Copy to Output Directory from Do not copy to Copy if newer (or Copy always). Now when you build, the folder structure and file are copied to the output folder (bin\Debug or bin\Release). -ner

Not sure if this will help, but have you tried changing the properties of your VB.NET 2005 project so that the target CPU is x86? It defaults to "Any CPU". At my work we've run into numerous issues running 64bit development machines - a lot of ASP.NET issues and a few 3rd party vendors that didn't have 64 bit versions of their controls. I was suspicious when some of my favorite utilities (such as UltraMon, for dual monitors) have separate versions for 32 and 64 bit. Even Windows Media Player is different between the two versions. Most of our devs have since switched to using a virtual machine setup as a 32bit windows xp and their main machine as 64 bit. Some of us (like me), opted to go for just a 32 bit windows xp even though the box is 64bit processor. -ner

I've noticed it as well - probably 1 to 3 a day. I just tried to register as a new user and there is the "advanced" feature of typing in the text that displays in a picture, all "mooshed" around. That helps prevent automated registrations so I'm guessing the spammers are 1 person at a time. I would guess they're individuals getting paid to spam boards such as these. I believe they still must register with a valid email address and wait for that, which further indicates individual spammers versus some automated process. Just my guess... -ner

I've used the free Express versions and they allow adding references to standard libraries such as Windows.Forms. At least, I'm about 95% sure they do. While you could program in Notepad, your productivity will be greatly reduced. I'd strongly suggest finding some kind of real IDE. There are a bunch of free ones in open source and many others that are cheap ($20 or so). ANYTHING would be better than notepad unless you're doing the simplest of coding examples. If you're doing such simple coding, then the Standard edition should be fine. I'd look into the #develop as mentioned as I hear it's quite good. You may like UltraEdit or TextPad as well, plus any number of free open source IDEs (even ones for Java have command line tools which would allow for calling out to the compiler). If you really want to learn how to program .NET from notepad, then do some google searches for something like ".net notepad". There are lots of hits. You'll need to decide how much of a learning curve you like, as using notepad means opening every file yourself (you won't see a list of project files) as well as figuring out all the command line arguments manually. -ner

If you just want a single string in the combo, and not a DataRowView, you could use the ComboBox's IndexOf method using your variable "head". If you have the original DataView you used to populate the drop-down then you might be able to use it's FindRows method to get a DataRowView array. Assuming your filter would get you exactly one row, you could use that in the ComboBox's IndexOf method. For example (my VB is rusty): Dim dv as DataView ' Assume set earlier '... ' Here is the filter, to find matching rows Dim matchingItems As DataRowView() = dv.FindRows(head) If matchingItems.Length > 1 Then cboHead.SelectedIndex = cboHead.IndexOf(matchingItems(0)) End If -ner

In the end it was easiest to just cut and past the BeginX and EndX methods from the 1.x generated web proxy code into a partial class. That way, I can use the new webmethods and the old ones (when needed). I only need the BeginX/EndX methods in a few cases (mostly for returning lookups), so the partial class works great. MS can reorganize my main webmethod files as needed without throwing away my BeginX/EndX methods. In a perfect world, the 100+ forms I already have written would be a lot cleaner, load faster, and have less business logic tied into the UI. Reality says this product is too big to do all at once and it will be years before it's in a state to revamp the UI's loading of data. There are so many things I'd like to change, to make the code nicer and give the user a better experience - but they're generally not paying for it and I don't have the time to do it on the side anymore. -ner

We don't usually mark threads as resolved or "still need assistance". Might be useful, but we've just never done it. -ner

In an ideal world, a UI could display before having all the data. In an ideal world, the data would be downloaded almost instantly and the user would never wait. In my world, I have to get at data. If a user clicks a menu item to open a form display customer data, they're not interested in doing anything else - they want their customer form to open. I could definitely let the user "not block" but then what? They still have a "Please wait..." message in front of them and they open something else? Seems kinda odd. If I didn't show them "Please wait..." then they'll have no idea that I started opening a form. I'm older, but I can't imagine another way to show a form without waiting for the data it needs - in another thread or not, that data has to be there. Using a real world product, like MS Word, they do the same thing. If I open a large word doc (say 56 meg), I don't get a responsive UI while the file loads. I get MS Word starting to open and it "hangs" until it opens. I suppose they could have let me click around the menus while I'm waiting, but that seems kinda pointless. So to answer #2 I did quite a bit more digging/investigating. The only thing working so far is to use Application.DoEvents(). While I'm not 100% sure, I'm guessing my situation is complicated by my use of static variables and methods. I won't go into details as my solution seems like PDs answer - go back to the way it was working in 1.x and hope that one day they put back that functionality. For now, I don't mind "recreating the wheel" for what I need, though I wish I didn't have to. Thanks for the help and insight, it's good to bounce ideas around to double check my thoughts. -ner

With IngisKahn's last statement, I couldn't disagree more. You block/wait for all sorts of things before showing a windows or web UI. If you've ever returned data from a database then your UI is blocking. Sure, you'll have a timeout on the connection - that's perfect. Hopefully you never get near that timeout value, but you're still blocking at some point. Take the common scenario of calling two stored procedures to get two sets of data. If you agree that you have to have this data before showing the UI then you'll be blocking. Standard code might do this: Form loads (OnLoad or Load event): Call stored proc to get lookups Call stored proc to get customer data Do some initialization that doesn't require data above Bind controls In this scenario, I'm blocking four times - twice for data and twice for standard WinForm code. Given that scenario, my implementation wants to start getting data asynchronously while the rest of the UI does what it can. At some point before the UI loads, that data has to be there. I guess my scenario is not as common as I'd hoped or no one else is optimizing the loading of their forms...? -ner

The biggest change is in using the parameter "e" passed to the event. It has the KeyCode and boolean values for Shift. For control and Alt, you'll need something like this: bool CtrlPressed = ((Control.ModifierKeys & Keys.Control) != 0); bool AltPressed = ((Control.ModifierKeys & Keys.Alt) != 0); You could also make this more generic by casing "sender" to TextBox. That way you wouldn't have to hard-code the name "Subject". It paves the way to you making your own custom control that just inherits from TextBox. -ner

I suppose my question can be broken into two: 1. Am I doing things the right 2. How do I do what I want I think most of the answers are for #1, while I need #2 :) marble's example is very close to what I want but moving logic into an event handler just doesn't make sense. Maybe that's the way it has to be done, but it's certainly not the way it should be done. Here's a better example: frmCustomer's constructor (assume all this logic is on the form somewhere): 1 Start getting lookups data from DB 2 Start getting customer data from DB 3 Start getting user "default" values from DB 4 Do some basic initialization that doesn't rely on any data above 5 Start building a business object that requires all 3 of above 6 Bind controls From that pseudo-code, there are three asynchronous calls. This code clearly needs to block/wait at the time it reaches step 5. While I'm sure you can come up with a way for the three event handlers to trigger some call to a function, which in turn checks that all three have finished, isn't it easier - and just as performant - to block/wait at step 5? It makes the code more readable as well. The code should mimic my intentions so that I can "see" what it's doing. I can see arguments for doing the binding in the event handler of getting the customer data - you could do that there. Same for the lookups - in their event handler, bind the drop-downs. But if you need multiple asynchronous calls to be finished before moving on, or if you just don't like the disconnected nature of the events and completion because it's not "nice", then why not provide an easier way to wait? I don't think anyone can argue that blocking is "bad" - we all block our UIs to wait for Customer data to load. We all block our UIs to wait for lookups (well, most of us do). We have to get data before we show the form, that's a simple fact. So, assuming the original question #1 is answered with "Yes, you are doing things right" maybe the answer to #2 is simply "I don't know." At least, that's my answer to #2. I'm thankful for those of you suggesting alternate routes to handle things asynchronously - it makes me triple check that I'm not doing something crazy. I honestly think I'm doing things the "best" way - especially when it comes to performance. I will investigate the BackgroundWorker class. Maybe I'll have to "code it by hand" after all, although this seems like such a common problem to solve. It seems odd that MS had support for this pattern (start the webmethod asynchronously and later on, wait for it to complete) then removed it. -ner

The problem remains quite simple - yet escapes me for 2.0. It was quite easy in 1.x but MS removed the ability to wait on an asynchronous webmethod. I can't use your suggestion of the Lookups class loading a form as they'd have no way of knowing what form to load. The pattern seems VERY common yet I can't find any clues while googling. It seems that this pattern would come up often - start downloading something asynchronously and at some point, when your app needs that download to finish, it must wait until that download is done. I may have to put in a call to MS if I can't find an answer soon. It seems a bit too common a problem to have to resort to implementing my own threading/asynchronous logic as MS provided it in 1.x and then changed it in 2.0. I'm betting there's something out there to do this, I just haven't found it yet. And I agree - unresponsive UIs suck. Alas, I can't currently reduce the amount of lookups being returned to the UI. The old code was worse because it wouldn't even begin to load lookups until the form was actually being loaded. The user gets a nice "please wait..." dialog but it took much longer to load as the code returning the lookups was a pure synchronous webmethod call. At least now, they get a headstart downloading. -ner

The way I use the Lookups class is that any form may call GetLookups and that form expects to get a Lookups object returned. The start of my application kicks off the downloading of the Lookups object by the async call. I need each form to block/wait for the lookups to finish coming down. The lookups MUST be there for other code on the form to run. So, the event doesn't help me if a form is loading and needs the lookups. Meaning, how do I make the form "wait" until the event fires? -ner

I'm not sure if the standard install comes with a user control that you can host. I'd look at that first to see if there's a control you can host on your form. Failing that, you can put a web browser control on your form and have it host the SWF file. -ner

In .NET 1.x, I got back an IAsynchResult (I think) object when I called BeginMethodName. I could hold onto the handle until I really needed the data, then call a Wait method to make sure the webmethod returned (or errored out). In .NET 2.0, they've implemented the Event-based Asynchronous Pattern. In this pattern, I hook up an event handler and then call MethodNameAsync. My trouble is, I can't figure out how to wait for method to finish from within WinForms. The scenario is this: Form1 is a search form that uses a static "Lookups" class. The "Lookups" class exposes a method that makes an asynchronous webmethod call to get some standard lookup tables from the DB. Form1 launches Form2 some time later. Form2 MUST have the lookups loaded so it needs to wait (or block) until the asynchronouse Lookups class has completed it's webmethod. I tried adding another static method in my "Lookups" class that goes into a "while(...) Sleep" loop, to wait for the Lookups to complete but that seems to block forever. What's the best way to use the asynch method and wait until it's done or at least safely check that it's done? Here's the relevent code: partial class Lookups { private static Lookups lookups; private static bool gettingLookupsAsynch = false; public static void StartLookupsAsync(string wsUrl) { // If lookups are already in memory, get out if (lookups != null) return; gettingLookupsAsynch = true; WebService webService = new WebService(); webService.Url = wsUrl; webService.GetLookupsCompleted += new GetLookupsCompletedEventHandler(Lookups_GetLookupsCompleted); webService.GetLookupsAsync(); } public static Lookups GetLookups(string wsUrl) { // If we already have the lookups, just return them if (lookups != null) return lookups; if (gettingLookupsAsynch) { // This is the problem code [b] while (lookups == null) { System.Threading.Thread.Sleep(1); } [/b] } else { // Not getting async, get them and wait WebService webService = new WebService(); webService.Url = wsUrl; lookups = webService.GetLookups(); } return lookups; } static void Lookups_GetLookupsCompleted(object sender, WebService.GetLookupsCompletedEventArgs e) { lookups = e.Result; } } From above, Form1 would call StartLookupsAsync(). Later, Form2 calls GetLookups. Since the asynch call was made, gettingLookupsAsync is true and GetLookups enters the while loop. The while loop appears to block forever. This is my failed attempt at getting it to work. If the event handler fires before GetLookups is called (which is most of the time), then everything works fine. I need help! (please!) -ner

You'll have to set the Location and Size properties themselves. Try this: OKButton.Location = New Point(81, 165) OKButton.Size = New Size(22, 65) -ner

I've noticed this, too. Even when the MaximizeBox is set to false the form will show maximized in MDI. Our solution was to use the Activated event of those forms that you don't want maximized and put in the following code: VB: Me.WindowState = FormWindowState.Normal C#: this.WindowState = FormWindowState.Normal; If you do it often, you can create a base form that handles this. For overall design, it's nice to have a few "base" forms. We have ApplicationForm, SearchForm, and DialogForm at our company. -ner

Since you're not doing any outer joins (no "*=" syntax), the translation needs two things: move the separated tables into "INNER JOIN" syntax, and add an "ON" clause to each join. First, I've moved each table into an INNER JOIN (invalid SQL syntax, just showing step 1): SELECT c.cust_id, c.name, c.address_1, c.address_2, c.address_3, c.city, c.state, c.zipcode, co.first_name, co.last_name , co.fax, sr.rep_name, sr.rep_phone, sr.rep_fax, sr.rep_email FROM customer c INNER JOIN contact co INNER JOIN sales_rep sr INNER JOIN customer_price cp WHERE ( c.static_cust_numb = cp.static_cust_numb ) and ( c.rep_id = sr.rep_id ) and ( cp.sales_code = @cp_sales_code ) AND ( c.employee_number = sr.employee_number or ( sr.territory = @sr_territory and sr.branch = c.branch )) AND ( c.status <> @customer_status ) AND ( c.rep_id = @rep_id ) AND ( co.default_contact = 'Y' AND c.static_cust_numb = co.static_cust_numb ) And the final: SELECT c.cust_id, c.name, c.address_1, c.address_2, c.address_3, c.city, c.state, c.zipcode, co.first_name, co.last_name , co.fax, sr.rep_name, sr.rep_phone, sr.rep_fax, sr.rep_email FROM customer c INNER JOIN contact co ON co.static_cust_numb = c.static_cust_numb INNER JOIN sales_rep sr ON sr.rep_id = c.rep_id AND ( (sr.employee_number = c.employee_number) OR ( sr.territory = @sr_territory and sr.branch = c.branch ) ) INNER JOIN customer_price cp ON cp.static_cust_numb = c.static_cust_numb WHERE c.status <> @customer_status AND c.rep_id = @rep_id AND cp.sales_code = @cp_sales_code AND co.default_contact = 'Y' Note that you can move the last two lines of the WHERE clause into the Joins if it makes more sense. If the joins were Outer Joins then you'd almost certainly want that logic moved into the join as leaving that kind of logic in the WHERE makes the join act like an inner join. I made an assumption that you always want to join to sales_rep by rep_id - check out the nested "AND (a OR (b and c))" clause to make sure it's right. -ner

If you have your procs in a Visual Studio Database project you also have the advantage of doing a search using regular expressions, which can better isolate table names. PD's example is what I generally use when I want a quick check. -ner