I wouldn't call it run-time resolution, but it seems that the actual data used for True and False are just integers 1 and 0, and the code compiles to an integer comparison. This will end up giving the same result as calling Boolean.CompareTo(Boolean). Seeing as none of the integral data types seem to have operators defined that I can see, I don't see any reason why the C# compiler should prevent you from using those expressions.

Luc Pattyn wrote: PS: nothing much has changed around here, has it? Same ol', same ol'. Mind you, I've spent the last month or so working on a bit of Open Source work along with Karl Shifflett, so I've spent less time in the forums as a result. Deja View - the feeling that you've seen this post before. My blog | My articles | MoXAML PowerToys

Well, it's not just us.. I got a skype call from an old sysad friend of mine who's got the exact same problem happening on 3 different continents since the last Server 2K3R2 update. In his case, installing and re-installing the .net runtimes fixed the issues he had, but this unfortunately doesn't work for us. He is running asp.net code on netfx v1.1, v2.0, v3.0 and v3.5, whereas *all* of our code is compiled against netfx v3.5 (i.e. 2.0 + extensions), so not the same config. However, we are now able to restore working service without rebooting by using NET STOP IISADMIN /Y followed by NET START W3SVC to force IIS to start over. I feel like I've just been time-warped 10 years into the past to the days of classic ASP and COM, *ugh* This still means the every website, web service and the ftp service have to be killed any time we want to make even the most *minor* change to any of our hosted apps (which is crap), but at least we're not going down for 2-3 minutes, and DNS and mail can continue to function throughout it all. Not a resolution, but at least a sloightly better work-around for us.

Furty wrote: helper.DoSomething(T); // won't compile That should compile. Furty wrote: helper.DoSomething(this); // won't compile That shouldn't compile. You are clearly passing the wrong type. ** xacc.ide-0.2.0.50 - now with partial MSBuild support! **

How about "Totally awesome data binding and data validation in .Net 2.0"? :doh:

You can create a class which wraps the actual data source, and exposes an augmented version of the data source with the extra item(s) in the list. Then bind the ComboBox to an instance of the wrapper class. Josh

Thanks bismark, that of course worked. After seeing all the improvements to data binding during design time, I had hoped the powers that be had built a better mousetrap for object binding in V2.0, but not so hey.

I get your point, since the web app actually runs somewhere in windows folder :doh: sorry I can't help you more with that. Any one else has suggestions? daniero

The Spam has been removed and the user's account disabled. cheers, Chris Maunder CodeProject.com : C++ MVP

Colin Angus Mackay wrote: that kind of interogation is likely to raise the heckles a bit. Nah, it's cool. I hate spam as much as the next person and I'd want to know that the person I give my email address to is looking after it. cheers, Chris Maunder

I've been in the same situation. If your software is distributed over the web to end users you have no control over, .NET is a HUGE requirement. I've asked this question in other forums and to some MS people; it's really strange how some people have a hard time understanding that .NET is indeed a very difficult pill for end users to swallow, thanks to it being over 21 MB. My thought is this: .NET will be everywhere by 2007. Until then, it's a guessing game; while a vast majority of desktops have XP, only some of them will have .NET. If your product is small, and will be finished within a year, and will be distributed over the web, I'd say use C or C++. If your product is fairly large project that will take a year or more to develop, or will be distributed on a physical media, then yes, write it in a .NET language for productivity's sake. By the time your product is released, many more users will have the .NET framework installed already, and you'd be even closer to Longhorn, when everyone will have the framework installed. My rant is that MS needs to get .NET to the masses sooner than Longhorn. If they would just bundle it with Office or IE, questions like these wouldn't arise and they'd get more developers writing .NET-based software. The graveyards are filled with indispensible men.

Heath Stewart wrote: How much memory does this person have in his machines? One has 64MB, the other 128MB, however my low-end test machine (that runs the app fine) has just 56MB usable RAM (8 MB is taken up by the video card). Heath Stewart wrote: Have you checked the MS KB? Yes. The only possibly related article I could find was a COM import bug in fx 1.0 that was fixed in 1.0 SP1. However, compiling the app for fx 1.1 should have worked around this issue if it was the problem. Heath Stewart wrote: Besides that, all I can think to tell you is to post a message to an appropriate MS newsgroup Have now posted the problem to microsoft.public.dotnet.framework, but as you noted and I've personally experienced, difficult questions seem to get lost in the ether... Thanks for your help anyway Heath

Kannan Kalyanaraman wrote: How long you took to complete this project ? The bulk of it was written in a very solid 4 months of working 14-18 hours a day - at that stage I had a very stable and functional beta. It took a further 3 months to polish, optimize and add the beta testers / test users feature recommendations. Kannan Kalyanaraman wrote: How much of it was done using vs.net ? 100%

It's on GotDotNet, that's why you can't find it on google (why they have a robots.txt file to stop spidering is beyond me), anyway you can find it here: SSLProxy[^]

I'll have to remember that, thanks for the heads-up. I suppose I should be glad I wrote a binary editor derived straight from Control, as I can see I would have had the problems you're having. Of course, much of TextBox's functionality didn't apply for me. Still a pain in the "details", so I see why you're trying to avoid it. Still, I'm curious as to why the problems. I'll post back if I find anything.

Yes, in fact here's the data from it right now (last line mangled intentionally): LastVisit 1%2F25%2F2003+10%3A53%3A22+PM www.thecodeproject.com/ 1536 226615296 29577624 530184256 XXXXXXXX * The question is, why would it think my last visit qas 1/25/2003, when it is in fact about 5 minutes ago. Note that because I have the cookie, I don't need to manually login - perhaps it is only setting the last visit date when I manually login?

Thanks for the tips Philip - after stopping one level before the MDI parent I still had a problem where the MDI child form was reporting negative location values. The final code I came up with looks like this: int x = Left; for (Control thisParent = Parent; thisParent != null; thisParent = thisParent.Parent) { if (thisParent.Parent != null && thisParent.Left > 0) x += thisParent.Left; } int y = Top; for (Control thisParent = Parent; thisParent != null; thisParent = thisParent.Parent) { if (thisParent.Parent != null && thisParent.Top > 0) y += thisParent.Top; }