PlausiblyDamp

What happens if you set the .Expires to a more reasonable value i.e. a year or two rather than .MaxValue?

You should be able to use a parameter to do this - I personally would always advise against using string concatenation to do DB stuff. If you swap the order you add the parameters in does that work? Also is there a reason you are using Me.EventNuclID as the name of the parameter in your code?

To reverse engineer a specific application, add in code for a key logger or similar, recompile and redeploy is an awful lot of work and most definately not a trivial undertaking regardless of the individuals age; most definately not within the abilities of the typical 'script kiddie' style of hacker. Plus this will have to be undertaken every time a new revision is released. As has been mentioned before - your best bet is to give your application a strong name and implement a policy of only fully trusting signed applications and restricting all non-signed applications to a safer subset of functionality rather than overly worrying about the possibility of reverse engineering.

GCHandle You wouldn't be able to do anything with it - if they are allocating them it is their responsibility to free them, they should be aware of how to free the handle as they are the ones that are allocating them in the first place so I doubt telling them about this is going to help. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfMemoryPerformanceCounters.asp is probably worth a glance over to explain what the various counters mean.

Have you looked in the Deployment part of the forum yet?

When you use the mouse wheel the MouseWheel event occurs, e.Delta tells you how much the wheel was turned by and the direction is indicated by the sign.

Does GroupBox1 contain anything other than CheckBoxes? If so that will cause it to fail. You will need to just cast to a control and then check if it is a checkbox

This has been raised many times already on these forums try any of the following for starters. http://www.xtremedotnettalk.com/showthread.php?t=92901 http://www.xtremedotnettalk.com/showthread.php?t=87289 http://www.xtremedotnettalk.com/showthread.php?t=77883 http://www.xtremedotnettalk.com/showthread.php?t=88916 http://www.xtremedotnettalk.com/showthread.php?t=82869 http://www.xtremedotnettalk.com/showthread.php?t=75908

If it's leaking GC Handles then I would personally class that as "a bad thing" ™ - a GC handle is a handle to a managed object that is being passed to an unmanaged API. If these are not being cleaned up then I would class it as a bug - pure and simple. GC Handles need to be explicitly freed by calling GCHandle.Free(), unfortunately there is nothing you can do to fix this as firstly it is a problem with their code and secondly a GCHandle is a value type and not at the mercy of the garbage collector.

Disposing of the DataReader is a good thing, setting it to nothing will not have any impact so you may as well remove it. It does look more like a SQL issue than a .Net one from the figures you are quoting, I would suggest you run the SQL profiler against the query and see what figures it gives for IO, CPU etc just to get a better feel for what it is doing, also from query analyzer you may want to investigate the graphical execution plan option to see which parts in particular are causing problems. If you can reduce the rows involved by a 'better' where clause then that is probably the first thing to try.

Have you tried running the CLRProfiler against your application to check where these allocations are coming from? What does this 3rd party control do? How much memory is it leaking? Unless the control is allocating critical resources it shouldn't need to tell the GC anything - when variables are no longer required the GC can free up the memory. If the variable isn't going out of scope then it makes no odds how often you call GC.Collect() there will be nothing to collect. If the problem really is the 3rd party control then have you contacted their support to see about a fix?

If you check in task manager (or use sysinternal's process explorer instead) is it your app or MSDE that is taking up all of the memory? As Wile says calling .Dispose() frees up the critical resources, you shouldn't normally need to set them to nothing as well as the GC will be capable of detecting when a variable is no longer used (are you doing a release build or a debug build?). Too be honest I have a feeling that the problem isn't really a .net one and it's more likely that your are running this on a PC with too litle RAM for what you are attempting - that would explain the rapid drop in free memory and large page file growth. Also MSDE is designed as a SQL - Lite kind of database and is deliberately constrained in terms of performance - if you are using tables that large you really should be using a full SQL product. If you just run the same query direct from Query Analyzer (or even osql.exe) does the same problem occur? Is there any way you could optimize the query?

The framework doesn't really expect XML files to be used concurrently by multiple people so I doubt there is an easy solution to this problem. Is there a reason why you require multiple people to edit the same document simultaneously?

Add a notifyicon control to your form and give it an icon, then handle the resize event and if your windowstate is minimized make yourself invisible.

Did you try stepping through in a debugger to see what happens? Have you tried it without the shared keyword and stepped through the relevant code? Also rather than just using a public variable have you trioed using a property instead and placing a breakpoint within the property set to see if it is getting called correctly?

Try Difference = DateReturnTP.Value.Subtract(DateReturnTP.Value)

You could restrict access via IIS manager this way but not through a web.config - restricting by IP is also not a good security model on it's own for anything other than a pure intranet application, and even then addresses can be spoofed.

Firstly is there a reason why you declared SupplierNumber as shared? It probably isn't required or offering any real benefit in this case. If you step through the code in a debugger is SupplierNumber actually being assigned to correctly?

What didn't work about it? Dim ts as TimeSpan = DateTime.Now - DateTime.MinValue MessageBox.Show(ts.TotalDays.ToString()) Does that work then?

Dim myYear as String myYear = DateTime.Now.Year.ToString()

Dim strText As String = "Account:" Dim myVar As String myVar = strText.Substring(0, strText.Length - 1) 'or Dim c As Char() = {":"} myVar = strText.TrimEnd(c)

Modules are not a particularly OO way to approach the problem - what happens if you have several forms that 'share' information this way? Sooner or later you will end up introducing bugs. For a better approach to passing information between forms etc you may want to give clicky a read.

The best method is to create the thumbnails separately using a graphics editing program to handle the resizing - this will give the best quality results. Alternatively the Image class has a .GetThumbnailImage() method that may be of some use.

Is the service running on your PC? If not try running aspnet_regiis /i on your pc and see if that fixes anything. You should be able to run both versions of the framework side by side though

Does either the key down or key up commands work or do both fail / just get ignored?