PlausiblyDamp

GetFiles just return the file names, just like GetDirectories returns a list of Directories. GetFileSystemEntries returns all Files and Directories.

Personally I tend to use early returns only as a 'guard clause' on a method i.e. when validating input as only using a single return can result in the entire method being an if block. i.e. //rather than public bool TestMethod(string s) { if ((string != null) || (string != String.Empty)) { //real code here //for many lines //which may not all fit on a single screen //which eventually results in a return true; } else { return false; } } //is far simpler to read as public bool TestMethod2(string s) { if ((s == null) || (s == String.Empty)) return false; //real code here //for many lines //which may not all fit on a single screen //which eventually results in a return true; }

The builtin class MasterPage is a class that other MasterPages inherit from and does not contain a definition for your AddCustomSection method. Rather than casting the MaterPage property to a MasterPage (which it already is) like you are doing with objMaster = DirectCast(Me.Master, MasterPage) you will need to declare it and cast it to the correct type Dim objMaster as EPPMasterPage 'Or whatever the name of the class for your master page is. objMaster = DirectCast(Me.Master, EPPMasterPage)

Does the working code use the same CreateFlags and CooperativeLevelFlags as your code?

http://www.xtremedotnettalk.com/showthread.php?t=49597 and then http://www.xtremedotnettalk.com/showthread.php?t=70920 might be worth having a look at, the 1st gives a good example of how to develop a plugin based system and the 2nd extends it to include GUI elements.

What user account is the service running as? Does this account have access to the Exchange server?

As far as I'm aware they are only available to the training centres and not for sale to the open market. Also they are not cheap and the training companies do pay quite a premium for them (and for the privilege of being a training centre). Personally I think a good training course is worth the time and money and should offer more than just the manual contents. If the course was not much more informative or helpful than reading the manual then something has gone wrong somewhere...

When you go to open the web site, File->Open Web Site you can select the type of access you want on the left, one option is local IIS. This will allow you to open it and run under IIS rather than the included web server. The same applies when you create a project, if you select file system as the location then it uses the built in server, select IIS and it will use IIS.

If you use the And keyword then both operands are evaluated regardless of the result of the 1st operand, AndAlso will only evaluate the second one if the first is true and therefore the second needs to be evaluated. We now get the Or and OrElse keywords which provide a similar level of functionality.

#define doesn't work like that under C# by design. It may help if you give a bit more detail about what / why you need this feature under C# as there may be a better alternative.

I've got to ask - what size monitors are your running to be able to display 3,000 textboxes? Even at 100 textboxes per tab a tab control would have over 30 tabs and barely fit on a normal sized screen... As has been said above DLLs are only really useful if you have logic that can be shared between applications and might not help in this case. You may find improvements can be made by identifying code that is duplicated between forms / controls on a form and moving that into reusable classes to reduce the overheads. I do think the number of controls per form is possibly the biggest contributing factor to the size and complexity here though, what is the need for so many and could some alternate technique not be used to reduce the number?

http://www.xtremedotnettalk.com/showthread.php?t=30544 has links to a couple of good tutorials.

Not sure if there is a bug in the lines Dim intP As Integer = msStream.Length - (hashsize * 8) intP = msStream.Length as you are assigning to intP in both cases but never using it in between.

Have you tried using a literal control rather than a label?

By finding out for yourself did you mean reading the FAQ?

Calling Application.DoEvents should fix the problem.

Is this running as part of an ASP.Net application? If so this code will execute on the server not the client pc. If you are trying to get a client's browser to execute the above code then it cannot be done this way. The Shell command is really just for compatability with VB6, Process.Start and the related classes are the prefered .Net way of doing things.

You could apply a css style to alter how they are displayed or are you after something else?

The myDonor method is the one that adds the entries to the array but you are never calling it, hence every array item contains the default values.

QueryString doesn't take up any server side resources, unlike Session variables which remain in memory for 20 minutes by default. Large amounts of information howerver may be impractical to send via querystrings. QueryStrings are also easily modified by a client and can lead to potential exploits or future problems if people have bookmarked the page. It may help if you give a bit more detail regarding the kind of information and the use it will be put to.

Use cs not csharp for the tags.

If you just launch the file itself the default application should be opened anyway, System.Diagnostics.Process.Start("c:\\boot.ini"); launches boot.ini in notepad as that is the default text editor on my system. You can also invoke any registered application through it's context menu verb like so System.Diagnostics.ProcessStartInfo si = new System.Diagnostics.ProcessStartInfo("C:\\boot.ini"); si.Verb = "Print"; System.Diagnostics.Process.Start(si); be aware that if you are running this on the server this will cause the application to be launched on the server not on the client's machine.

If you are going the Unit Tests route (and you really should IMNSHO) then as mskeel says treat the test code as if it was part of the source code and apply the same principles to it as you do to the main 'trunk' of the application. Having the tests means you can reorganise and tidy your code knowing that you aren't making it any worse functionally while making it tidier / more readable etc. having this knowledge will give you more confidence in actually performing the refactoring itself, this is only of any real benefit if you can read, understand and maintain the tests themselves though. Get in the habit of doing this as you go i.e. code something and then when you are sure it works rather than move on to something else examine what you have done (both application code and test code) : Is it readable? Is it clear what the code is doing? Do the variable / method / parameter / class names give a clear indication of their meaning? Are the comments sufficient / clear / accurate / needed? If any of these are not a definite yes then fix things now rather than letting poor quality code get embedded into the system. Then retest. Similar to the DRY principle mskeel mentions a lot of TDD developers go by the term OAOO (Once And Only Once), however that is generally the 2nd most important rule to apply to your code - the 1st being 'Does the code clearly express it's intent'. i.e. If duplication of a piece of code makes the code clearer to read then the duplication is fine, if the duplication doesn't add to the programmers understanding then it needs to be removed; a less efficient (but adequately performing algorithm) may be better than a more performant but less understandable one depending on the situation. Do this as part of your routine - when you check your code like I suggest above also check for duplications etc and if you can identify methods / interfaces / base classes that could be defined to simplify the code even more do it now. Then retest. Also the idea of keeping things simple i.e. only solve the problem in front of you - do not create massively complex architectures 'just in case' they are needed later; if they are needed later then code them later - if they are never needed think of the time saved. This method also means because you never make any great leaps of faith in code changes you are going from a working state to another working state without ever causing major problems. One of the biggest causes of poor quality code is that once written code is rarely maintained unless things go wrong - then it is normally a patch to the code (often of lower quality than the original code) rather than a proper revision. Routine maintenance of any other system (production lines, electrical installations, cars etc.) is taken for granted - why should source code be any different?

Try changing the end of the routine to 'Objects Cleanup tmpGraphics.Dispose() tmpResBitmap.Dispose() tmpBitmap.Dispose() Calling dispose should free up the non-managed memory etc. used by the bitmap objects, setting them to nothing won't have any impact on the memory being freed so there is no need to include those lines.

What does your SQL look like? You could always use an output parameter in your stored proc to return @@rowcount or similar.