divil

Putting uninstall programs in the start menu is a very Windows 95 thing to do. It hasn't been the trend in recent years at all. It's like wanting to right-align your Help menu or use an INI file to store settings.

The correct way to get an assembly's version is not by reading an attribute, but by looking at the Assembly.GetName().Version property.

I and virtual every programmer I've discussed it with finds Pascal syntax nauseating. By the way, real class factories are trivial with VB6 using tlbinf32.

I absolutely agree. The same goes for any language, not just VB. God forbid a new programmer builds a dependence on Pascal syntax and Delphi objects rather than learning language-neutral programming concepts. You seem to be arguing against a point I never made. So far I have only taken issue with your generalisations about "vb programmers" and their skills. You throw out comments like "VB'ers need not apply", "A VBer only knows how to enable and disable menu items" and "learn to program!!!". You have yet to clarify what makes a "VB'er", but if you're talking about a programmer who knows VB (as would be the logical assumption) then your statements are wildly inaccurate. I'm sure I don't need to remind anyone here that the most pointless arguments of all are the "my language is better than yours" arguments. They further nobody. Remember that how useful a language is goes beyond what features it does or doesn't have, to how appropriate it is for development in the workplace (the same applies for hobbyists only less so).

What you personally may or may not have a use for isn't really relevant - the point is that your personal feelings aside, VB was and is the most popular programming language around. And no, that isn't just for hobbyists. VB ensured its success in the business world by moving in to the COM and natively-compiled world with VB5, so developing business objects and entire n-tier systems suddenly became a real possibility. The savings possible using VB over C/C++ were and still are immense. I'm sure you'll come back saying Delphi offered similar savings, and I won't dispute that because my Delphi knowledge is not broad enough to comment. My only experience is the Delphi business objects I have encountered in the field, and I'll let you know when I do. This isn't the right thread to ask your Visual Studio question in, but I've a suspicion outbursts like "learn to program!!!" directed at the countless people on this board who make a living writing VB won't do you any favours when it comes to answers.

VS.NET has all the designer features of Frontpage and more - it also doesn't leave your HTML code looking a complete mess. Just a partial mess. Personally I'm against WYSIWYG html designers.

Do you want this moved to the tutor's corner?

I'm no expert on what the different decompilers can or cannot do, but the initialization will certainly be visible in a disassembly so don't get the idea that your code is protected in some way.

It just means the decompiler you used doesn't know how to reconstruct the array initialization.

Is there something wrong with the detailed explanations on these topics that MSDN gives you?

Time for a generalisation of my own. Every Delphi advocate I have encountered, including Mr Mamma here, has been passionate about their dislike for VB. I have several theories as to why this is, but my favourite is that VB was always a language/environment with a comparable featureset to Delphi, but VB actually has a job market. VB is very much like Delphi in that it is very much an evolution of a language originally created a long time ago. Pascal was designed as an educational programming language. BASIC was written for beginners to programming. I find it interesting how someone can register on a forum and, within 5 posts, have attacked one of the major languages supported by that forum so many times. Certainly nobody who attacks a particular programming language or makes gross (and not to mention inaccurate) assumptions about the people who use it makes it past an interview with me. Thanks for introducing yourself, Joe Mamma.

Are you creating the NotifyIcon in code? If you've done it via the designer, it will be added to the components collection of the form and disposed correctly. If you are creating it manually, you'll need to call its Dispose method yourself in the Close event.

Why are you doing this? I told you, the only thing you need to handle is the Close event. Nothing more. And in your mnuClose_Click event, ONLY put Me.Close(). The notify icon will remove itself correctly. If Visual Studio doesn't exit debug mode, you have other problems.

Now is not a good time to be investing time in writing a grid control. There's a brand new grid control in the next version of .net that will be fully customizable and promises to beat most of the commercial ones out there at the moment.

The correct way is to listen to the Close event. As long as you just have Close() in your File -> Exit menu event handler, that event will get called either way. "All heck" will not break loose.

I speak only from experience. I have a site hosted on there that has very odd behaviour, they overload their servers. Sessions are spontaneously lost, things like that.

System.Diagnostics.Debugger.IsAttached

If uptime and reliability is a consideration, I wouldn't go with Brinkster.

More importantly, why is it referencing that file? .NET has more than enough XML handling stuff of its own in System.Xml.

Are you sure this is the event you're looking for? It's designed to fire once all windows messages have been processed and there are no more left in the queue. Then it won't fire again until after some more windows messages have been processed. Are you sure a timer wouldn't be more appropriate?

Bear in mind that if you're a professional developer and you look at this code, it could pretty much ruin your chances of getting hired, _anywhere_. Companies won't want you (even accidentally) using techniques garnered from that source as it could mean the end of their business if Microsoft finds out.

GDI+ objects shouldn't be form-scoped variables. They should only have very short lifetimes, otherwise you'll find Windows disposing of them after a while. You should create and dispose of them all within one render cycle. By the way.. if a system tray icon started doing that to me, I'd terminate the process and remove any trace of the application from my system.

It's also worth noting that this matter would have been dealt with in private if you had not chosen to disallow private messages in your profile.

GDI+ and .NET can only use TrueType fonts.

I absolutely agree that this server should be kept free of anything opensource and be purely IIS 6 with .NET 1.1, running on Windows Server 2003. You should not place bandwidth restriction on this kind of shared hosting account, otherwise the competition will win out. Either that or impose something high (like 10gigs easily upgradable). All web hosting accounts should offer a free SQL Server database (on a different server machine obviously) with a space limit of initially 10 to 20 megs, upgradable to more on demand. The space quota for the website itself should start at 100 meg and be upgradable on demand. The sql database should be available over the internet via enterprise manager. There should be a control panel to manage email accounts, all my hosting providers in the past have given me the option of unlimited pop3 accounts and I've never used more than 5. Your support response is vital, if someone drops you an email saying they want x directory to be made an application within IIS it should be done in a matter of hours. A ticketing system is a nice feature as far as support goes. Of course the most vital thing of all is uptime but I don't need to tell you that. Providing an uptime guarantee will attract a lot of professional customers. I also believe these customers will be attracted rather than repelled by the "pure .net" status of this package. I would expect to pay between £15 and £20/mo for such an account.