Wraith

commandline builds with devenv seem to break the metadata store that the UI uses keep track of the type of things. Until the IDE is forced to re-touch the files and update that database the wrong icons will be used on the class/file views and sometime i've found things won't compile cleanly. Its a pain in the arse but you need to go through and make it reparse each code file in the solution.

You cna't remove the security demand, the framework has the security required built into it and if the caller lacks those permissions an exception will be thrown. Create a RegistryPermission instance for the key you want to access. Create a try block with a specific catch for SecurityException. In the try first Demand() your permission, if it fails execution will continue in the SecurityException catch, if it succeeds then yout try block continues. Work with the key you want in the try region. This is a quick adaption of the code i'm using to access the registry, its not copy-past able since its snipped from a much longer function ut it shows the structure i'm using to get the job done. RegistryKey key = Registry.CurrentUser; string subkey = "subkey"; RegistryKey hive = null; RegistryPermission permit=null if (permit==null) { permit = new RegistryPermission( (RegistryPermissionAccess.Write|RegistryPermissionAccess.Create), (key.Name @"\"+ subkey) ); } try { permit.Demand(); try { key = hive.OpenSubKey(subkey,true); if (key==null) { key=hive.CreateSubKey(subkey); } } catch (ArgumentNullException ane){Log.WriteError("name is null",ane);} catch (ArgumentException ae){Log.WriteError("name too long",ae);} catch (ObjectDisposedException ode){Log.WriteError("key is closed",ode);} catch (SecurityException se){Log.WriteError("not permitted",se); throw;} } catch (SecurityException /*se*/) { key=null; Log.Write("Demand for permission to "+ subkey +" failed"); //Log.Write("permit = " + Environment.NewLine + // " Read ="+permit.GetPathList(RegistryPermissionAccess.Read) + Environment.NewLine+ // " Write ="+permit.GetPathList(RegistryPermissionAccess.Write) + Environment.NewLine+ // " Create="+permit.GetPathList(RegistryPermissionAccess.Create) // ); throw; }

Some exceptions require a lot of setup which is only jitted and executed when the exception is needed, which is sensible. When you throw the exception a stacktrace will be created which is a tricky job and requires that the stack hierarchy not be changing underneath it, that means it can be slow. When the exception if formed the runtime has to walk the stack looking for active exception handlers and determining if they apply to the particular exception it is throwing, again this can be understandably slow. Certain types of exception (COMException and Win32Exception) may also require pinvoke marshalling and incur even more time penalty on use. In the case of windows forms i find it not unusual to have a stack depth of 20+ methods even on the simplest events. Windows forms is a complex wrapper around the native windows implementation and its big in both depth and breadth. Exceptions are slow, avoid where humanly possible.

Just translate it into VB, the function declaration doesn't use anything that doesn't have a direct analogue in VB so its a relatively straightforward task. Look up each part of the declaration, work out the VB syntax, next section. Totally untested: Public NotInheritable Class ShlWapi 'BOOL PathIsDirectoryEmpty( ' LPCTSTR pszPath ' ); <DllImport("shlwapi.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _ Public Shared Function PathIsDirectoryEmpty( _ <InAttribute(), MarshalAs(UnmanagedType.LPTStr)> ByVal pszPath As String _ ) _ As <MarshalAs(UnmanagedType.Bool)> Boolean ' leave body emtpy End Function ' or Declare Auto Function PathIsDirectoryEmpty Lib "shlwapi.dll" _ (<InAttribute(), MarshalAs(UnmanagedType.LPTStr)> ByVal pszPath As String) _ As <MarshalAs(UnmanagedType.Bool)> Boolean End Class I'd suggest you learn c# because it'll help you a lot when you need to use code samples from c# in VB and there seem to be very few useful code samples in VB. VB syntax is really annoying when it comes to pinvoke, the c# may look a bit messy but at least i don't have to mess around with stupid line continuations and bizzare pascal style assignment operators for attributes.

There is a specific win32 api function in the shell api dll for this. public sealed class Shlwapi { /* BOOL PathIsDirectoryEmpty( LPCTSTR pszPath ); */ [DllImport("shlwapi.dll",CharSet=CharSet.Auto,SetLastError=true)] [return: MarshalAs(UnmanagedType.Bool)] public static extern bool PathIsDirectoryEmpty( [in,MarshalAs(UnmanagedType.LPTStr)] string pszPath ); } The c# managed method will call the underlying api and construct an array of directory names, multiple string marshalling steps if the directory isn't empty increasing in overhead as the number of entries increases. The FindFirstFile method requires strings and handles to be marshalled in and out and will require multiple calls because it returns . and .. entries, plus it needs the FindClose() call. This single call marshals one string out and an int/bool back. It probably uses FindFirstFile internally but that is handled in native code so it incurs no marshalling overhead. This is all conjecture obviously, if someone wants to work up test cases and test the speed i'd be interested to know if i'm right.

If a user looks at the numbers in the task manager and doesn't understand them they might think the memory usage of your app is a bit big. On the other hand they are making a number of errors in that decision and much as we may like to grab them and shake sense into them from time to time you really can't make users sensible. If they bad decisions through misinterpreting data then you have to let them, overall it is their loss. I understand your reasons but i think perhaps you are over weighting them. The ruintime has a set of tuned parameters it uses, when a process starts it'll make a number of allocations for stacks heaps etc. These numbers are abritrary and are tuned for an average process. You may need more stack or heap space or you may need less. Until you get to actually executing the code you really can't tell. If there is unused space then you could i suppose think of it as wasted. In reality these lazy little things help you by not taking processor time to maintain a minimum environment for your application. Unless there is memory pressure nothing else is going to want the wasted memory, you only waste time freeing it and resizing everything. This ties into my comment about GC Collect frequency. I wasn't trying to tell you that GC.Collect is usually a bad idea, you already knew that. I was pointing out that no matter what you allocate and deallocate unless there is a good reason for a collection to occur like memory pressure heap fragmentation etc then it won't. The program can just keep allocating objects and discarding them without them being removed from memory.

Because when its visible it needs to have memory available for the canvas it draws itself on. Since apps draw themselves they use their own memory to hold this memory. When you minimize there is no visible presence and the memory footprint seems to lower. It doesn't actually lower, the pages simply become availble for other processes should there be memory pressure. The vm size for the application doesn't change. I think, i may be a bit off but the general idea is right. No. When you dispose it will clean up any unmanaged resources (and perhaps some larger managed ones) and should remove the object from the finalization queue. However, the object still exists and references to it will still be valid which is why the framework has the ObjectDisposedException. When you set it to null you simply set the reference to null which doesn't affect the object at all. The object will be destroyed when a collection occurs if and only if there are no active roots for the object. If there is any single active root such as a stack based reference a GC reference/handle or one of the more obscure references then the object won't get collected even if it has been disposed. Garbage collections really don't very often happen unless your app hits memory pressure in some way, there isn't really a reason to collect anything most of the time and it can only hurt performance if it happens while your app is working. Just how much memory are you talking about here? If the app feels it needs the memory why are you second guessing both windows and the .NET framework. Its unlikely to be a leak, not impossible but unlikely. The memory is being used for some reason or it wouldn't have been allocated. Let the underlying systems do their job and worry about making your app a good experience for the users. In spirit it is intended this is true, but it isn't entirely accurate. The design guidelines say that the .Dispose method of items implementing the IDisposable interface should remove the object from the finalization queue using GC.SuppressFinalization(), if you follow this guideline and call the dispose method (explicitly or implicitly including using the using pattern etc) the Finalize (destructor in c#) will not be called when the object is collected. If your class is disposable do your cleanup in .Dispose() and call it from the .dtor method.

You write a class which implements IExtenderProvider and use it to link the tooltip to the menu item. Specifically in this case you subscribe to the Select event of the MenuItem and use that to set a specified Text property on another control. Its not so hard to implement once you've read around the subject of the componant model and IExtenderProvider a little, have a look.

When the errorprovider needs to set the error state marshal the call which will interact with the visual componant(s) back to the ui thread using form.InvokeRequired and form.Invoke, otherwise you will get unexpected and possibly wrong behavior.

If you think the classic interface is ugly thats fine, i'll stick with it though because i like it, we're both happy. The moment you start forcing one interface on people though you're in dodgey territory. One thing you should appreciate about the windows interface (skinned or not) is that it is designed to be consistant, and it is remarkably so. The guidelines show you how to write programs that confirm to standard usage patterns, thing slike copy paste, file and edit menus, they're standard only because if you put them somewhere else or use different names or accessor keys you will confuse your users. If you force people to use a skinned application you blow away any previous experience they have and force them to learn your program as a separate system. This means that people will use your program slowly and relcutantly if they continue to use it at all. You should try to make your program as familiar as possible and conform to user preferences whereever possible to minimize the new ideas that users need to know. Microsoft and other may well be skinning their applications, but i'm not using them and i hate skinned applications that don't let me use a classic theme. I don't have resources to space and i don't need irritating applications taking it upon themselves to ignore my preferences and wasting my resources. By all means skin things, make sure that if people are using Luna or some other skin that your application matches and makes the experience as easy as possible. But don't force skin to a new look/paradigm, thats just silly.

You could also respect the users preferences and only use the native skinning (where applicable) instead of forcing them to use a Luna interface. I'm still using win2k and any program that tried to force a Luna interface on me is isn't getting opened a second time if i can help it. You'd have to have a _really_ good reason to ignore user preferences and get away with it.

Of course you don't, that would be a daft way to implement the functionality you want. Use remoting, send a message to the minimized app telling it to restore itself, no windows handles or native apis needed.

The typical answer to this sort of question is remoting. Quite what pattern you would use to achieve your desired functionality i've no idea but in theory you get all your instances to listen to a single channel or published object and signal events through it.

You can add very simple commands through the registry and creating new verbs. To do anythign complicated thoug you need to use an IContextMenu implementing shell extension com class. Read the MSDN pages about context menu handlers and get ready for some interop. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_extending/extensionhandlers/contextmenuhandlers.asp

Your post is a little confusing, i'm not sure exactly what it is you want. Any executable can be run by directly executing its exe file, either from the shell or from the command prompt. To have your program the default for a certain type of file you would need to create a file association. The installer project has a tab for these and there is good msdn documentation on how to create them manually if you need to. Is this what you want to know?

Or theres the DefaultValueAttribute if you're working with the componantmodel, which you are if its a form/control and you're not if its a standard class.

Be careful to convert the paths from \ seperated to / seperated otherwise you won't get folder structure back when you unzip.

try FileDrop instead of expecting windows explorer to send you tree nodes.

I think you can find that information using the IPropertyStorage interface. Having looked at it though i have to say i'm glad i don't have to try and pinvoke my way through that interface and related structures, it looks like a nightmare. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/stg/stg/ipropertystorage.asp should get you started.

If hes got lots of colour code i expect it'd mount up, but he'd have a have a serious amount of code dealing with colours. Code size shouldn't really be a concern. if you can make the code smaller by making longer functions into smaller ones thats usually good because its code re-use. Smaller code in itself is a pointless goal if it takes longer to read. Afterall the compiler really doesn't care how long the code it only how correct it is, and the more direct you are in your code the less instructions dealing with indirection will be created (before any compiler optimisation of course).

The copyhook can only detect file move delete or rename operations. What you want to do would need to be a filesystem driver filter. I don't recommend trying this without some serious reading about the subject, and yes it would have to be in c.

To do what you actually said you wanted you'd have to write a filesystem filter driver, which runs in kernel mode as a drive if i remember correctly, and you can't write such things in .NET. Probably not want you want. On the other hand if you just want to block things from the windows shell (windows explorer not the command prompt) its relatively easy to implement the ICopyHook COM interface. The ICopyHook interface allows you to catch and prevent/alter all file/folder operations performed through the shell. Look it up on msdn and break out the System.Runtime.InteropServices namespace. For a more complete answer i'd have to know what you want to block and why, can you tell us?

vc++ compiles managed code to IL and unmanaged code to native instructions. You can't use managed code in _asm. Read the docs and the articles, this sort of thing is covered. There is also the problem that because IL is interpreted at runtime you can't debug at the IL level because there is no direct corresondance between the wto instruction sets.

In the first place C# doesn't compile to assembly code. C# is compiled to intermediate language (IL) instructions so you really can't just dump a chunk of native code into the linker and have it work. There is no _il keyword to let you type a chunk of native IL instructions either. I think this is because you should not be working at this level in c# or any other/net language. The compilers make a lot of optimisations and take into account far more than you'd expect, they are much more likely to make 100% correct optimisations than any single user is unless that used it very knowledgable.