PlausiblyDamp

If you are loading the bitmap into memory it might be worth keeping it in ram and using the image data directly rather than bothering with an array of points - given a known height and width it is pretty easy to convert an xy coordinate to a pixel directly. You could even optimise the checks a bit more - your image could be divided into about 5 rectangles to hint at the state. e.g. The top and bottom are entirely black to a point so you could just check if the y coordinate is above or below these cut off points and ignore the x coordinate if it is. Even if this is slow it will still be quicker than dragging the image from the back buffer to do the same kind of checks anyway.

Math formulas may be time consuming but you can make optimisations to the general idea e.g. rather than doing pixel perfect collision check against a rectangular bounding box and only check the actual pixels if a collision with this rectangle is found. Reading from the back buffer will always be orders of magnitude slower than the time taken by the video card to render the image itself. As an example I took a screenshot from a game at 1360 x 768 resolution and converted it to a 24bit bitmap - this weighed in at approx 3MB. That means to do collision detection using the back buffer on this sized screen you would be dragging approx 3MB per frame out of video memory to system memory. If your game is running at just 25fps that means you are having to move 75M a second out of the video card, on top of all the information being sent to the video card. Although video cards do provide a means to read the back buffer from them it isn't really the ideal scenario and it is not designed to be a high performance operation.

In practice reading from the back buffer will always be a slow operation as it involves dragging bytes from the video card to system memory and this requires GPU / CPU interaction. It is always going to be better in performance terms to do collision detection as part of the game loop based on the game state rather than relying on the rendered graphics. As part of your game state you should know the position / rotation of all objects and the textures being rendered so you should be able to detect collisions that way. http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series2D/Coll_Detection_Overview.php is part of a bigger tutorial (XNA but the concepts are the same) that deals with collision detection and is well worth a read.

If you are using the code "as is" then you will get errors because as you said it was written for VB6. Those registry keys will be the same regardless of language and switching the linked code to use the classes under Microsoft.Win32.Registry wouldn't be too difficult, not exciting admittedly but certainly not difficult.

Although the code is for VB6 the registry keys would be the same regardless of the language used, you could use the .Net registry classes to modify those keys and get the same effect. The article states XP as it was written at a time before Vista / Windows 7 and those registry keys should work the same on later versions of windows as well.

If you want to assign a value that is another type then the cast operator linked to above should do the trick. If you want to be able to define a variable of your structure and assign a value to it then you would need to create a constructor for it. If you search these forums there should be a few examples of how to create and use a constructor.

Not entirely sure what you mean by make a struct be a certain type, if you wanted to cast to a different type then you could simply overload the conversion operator to work with different types.

In C# you can do this by creating conversion operators - http://msdn.microsoft.com/en-us/library/xhbhezf4(v=VS.71).aspx gives a quick starting point on how to convert from a byte to a custom type - should be enough to get you started.

Have you considered looking on ebay for a solution?

What servers is it detecting? Is the database already defined or is this something you also need to create?

Tried it on a quick test project here and they fired just fine when the form was hidden, what version of .Net are you using?

Are you sure the event handlers are connected to the events themselves? If you used the designer to generate them it should have attached the event handler in the form1.designer.cs file; otherwise you will need to explicitly wire the event handlers together e.g. public Form1() { InitializeComponent(); FormClosed+=Form1_FormClosed; FormClosing+= Form1_FormClosing; } Out of curiosity is there a reason you are setting the MDIParent property and also adding the frmParent variable? It seems the frmParent could always be found by checkingthe MDIParent property.

http://code.msdn.microsoft.com/WindowsAPICodePack is probably your best bet, it has a fair few samples of accessing the various Windows 7 apis from .Net code including the progress overlay feature.

http://msdn.microsoft.com/en-us/library/aa394515%28VS.85%29.aspx - oh well. Depending on what you are doing it might be easier to just schedule a defrag run using the task scheduler included with xp itself.

The above code runs with no errors on my laptop... Which line throws the exception? What os are you running on the computer in question?

The ComputerName bit isn't really needed, didn't realise I had left it in - I threw that sample together in a bit of a rush :o

Re: Error: "managed PInvoke signature does not match the unmanaged target signature." If you are using VS 2005 or later simply bring up the project properties and there should be a tab for settings on the left. You can then provide settings with a name, type and default value while specifying if they are stored at the user or application level. At run time you can then refer to these settings via the My.Settings object. I am also not sure what the support for the various PrivateProfileString functions is under 64 bit versions of windows, it was only carried over to the 32 bit versions for compatability with 16 bit windows, you may find 64 bit apps are unable to use this call.

Re: Error: "managed PInvoke signature does not match the unmanaged target signature." Did you get the declaration from a VB6 source? Under .Net you might want to try changing the Longs to Integers and see if that helps. Then again if you are using .Net you might want to look at using a more .Net based solution such as the application settings as a way to store configuration information. Storing the config in the same folder as the application will cause problems for non admin users on xp or later due to permissions on the program files folder.

Something like Dim ComputerName As String = "" Dim wmi As New ManagementObjectSearcher("Select * from Win32_Volume Where Name = 'C:\\'") Dim volumes As ManagementObjectCollection volumes = wmi.Get() For Each Volume As ManagementObject In volumes Volume.InvokeMethod("Defrag", Nothing) Next should do the trick, you will need to add a reference to System.Management.dll as well for it to compile.

Is there any reason why you can't just catch the exception and move on? If you write code to loop over the modules and look at which ones throw the access denied exception and then look at the output from tasklist /m you will see that the output from takslist simply puts "n/a" for these entries - so it looks like they are just doing the same thing.

According to http://msdn.microsoft.com/en-us/library/aa394399%28VS.85%29.aspx it looks as the the Win32_ScheduledJob has a Name property, have you tried either searching on this or if that isn't possible you could loop over all jobs and compare the name property yourself.

What is the name of the .exe? Does it require admin rights to perform it's functions?

On the receiving end have you tried creating as memory stream over the byte array and the de-serializing from this memory stream?

Are you generating the viewstate on the autopostback but creating the controls in the page_load? If so you are processing the page load before you are changing the viewstate, you might want to also manage the UI changes from the autopostback event as well.

Doing a Debug.WriteLine would be far preferable to using MessageBox calls - Debug commands do not get compiled into a release build and do not change the user experience either. If you have a lot of these message box calls you run the risk of either forgetting to remove them all before releasing the software or while removing them you break the application in some small way by accident.