Well, if you don’t know what VLC player is, then I guess you must have been abducted by aliens for the past few years. In which case, welcome back! VLC is a cross platform media player with a somewhat quirky interface, but whereas say Windoze Media Player relies on codecs – a nightmare of codec incompatibilities exist there Read more
Some images – especially JPGs – can contain extended metadata. For example, if the image is from a camera then the camera manufacturer, exposure, focal length, flash details and such may well be added as metadata. Read more
I suspect nobody at at Microsoft deals with projects which contain a mix of C++ and C# code (typically this might be a C++ DLL called from a C# .NET UI). If they did, they’d very quickly realise the stupidity of not copying the C++ project output into the C# project’s output directory.
You might expect that adding the C++ project to the C# project as a dependency would make it plain to the Visual Studio IDE that perhaps it really ought to consider ensuring the latest C++ DLL appears in teh C# project’s target directory. But no, it does nothing (and is why I’ve tagged this as a Visual Studio Bug).
You can of course create a post build event in the C# project to copy the C++ DLL into the target directory. But if you modify the C++ DLL, the C# project doesn’t think it needs to build, ergo, does not run build events. Understandable – but annoying.
One “fix” would be to have the C++ project, as part of its post build, write to a skeleton .cs file that does nothing but is part of the C# project. Then the C# project THINKS its been modified and runs its post build where you then copy the C++ DLL across.
Not brilliant.But the skeleton file will then have a later date/time than the last C# project build date time and the C# project will build again – very quickly too since almost nothing has changed.
But that suggested another solution of sorts. Create a file – any file – lets say a text file. Set its date/time to way into the future, like 2050 or something, make it write-protected and add it to the C# solution with the properties of “build action = none” and “do not copy” to output. The project now has a file that is always dated after the last build so always builds, always runs the post-build event in which you can always ensure the latest C++ DLL gets copied to the target directory.
With luck, the only thing you need to remember is to restore the file date/time whenever the text file is re-created when restoring from, say, subversion.
Well, I guess I wasn’t paying attention when I added an image to my solution that had the same name, but different file extension, to an existing image. Of course, Visual Studio gives the image a default name equal to the file name without extension, but doesn’t bother checking for duplicates names before adding it. Only after it is added does it bother checking, at which point it gives a rather pointless error message:
“There is already another resource with the name,,,” isn’t very helpful when there is no offer of a solution to the problem ! You can no longer access the resources in the normal way and hence can’t delete the offending duplicate.
You need to open your application’s resources.resx directly as text, then search through all the sections that begin “<data name=” and delete the duplicate – with luck it will be the one most recently added and appear towards the end of the file.
Just delete the offending <data> section (s).
When creating custom controls you may want your control to not do certain things when it is being used inside the Visual Studio forms designer. Perhaps in the constructor for your control you want to connect to a database, or maybe create a window, or whatever but only want that to happen at run time.
Behold, there appears to be just the function you want – DesignMode – a nice little boolean you can query in your code.
But beware ! This little doozey is incorrectly named. It should be named “TheDesignerCanAccessMyPropertiesAndIHaveAnISiteAndImInDesignMode”. You see,
Oh cripes ! What are we going to do ?
Well, assuming you can live with point #2 above and if you are deriving from System.Windows.UserControl or System.Windows.Form then perhaps you could override OnCreateControl and do your initialisation there instead, since their Site property will have been initialised before then and hence DesignMode will be reliable. To be honest, OnCreateControl is often a better place to perform initialisation than the constructor.
What if you can’t live with point #2 ? Well, you could rely on whoever designed Control ‘B’ to recurse up through the Parent properties until you either find one with DesignMode set to true, or until you reach the top (Parent = null) in which case you you aren’t design mode.
Typically you derive from System.ComponentModel.Component when designing components you can drop on a form but in fact live on that panel at the bottom of the designer (where you often find your SystemMenu, Timers, or such like]. The clue to the answer is my alternative name for Micro$oft’s DesignMode i.e.
TheDesignerCanAccessMyPropertiesAndIHaveAnISiteAndImInDesignMode
You can override the Site property and when it is being set to a non-null value you can query the supplied ISite‘s DesignMode and perform your initialisation based on that value.
As for getting around point #2 … well, good luck with that one !
Are there any other ways ? Well, there is System.ComponentModel.LicenseManager.UsageMode (yes, thats right, LicenseManager!) which you can query to see if it’s value is set to “runtime” but if MSDN is to believed (and why not, it is known to be a 100% reliable source of information isn’t it [snigger]) it requires at least Vista SP2. Oh, and it might only work in a constructor – it certainly doesn’t work inside events.
Assuming for a moment you only program using VisualStudio under Windows and not some other environment (such as the excellent Mono). Well, you could get the name of the currently running process and see if it is called “devenv” [Hack alert, awooga! awooga!]. One line of code to fix it in all situations and you aren’t limited to forms, user controls and components, any class can do it:
Which, of course, will work right up to the point where Micro$oft find out we are doing this and go and change it in the next Visual Studio service pack just to annoy us.
Yep, there is just one more way we can tackle this problem:
Petition Micro$oft to give us a DesignMode property that tells us when we are in design mode !. Sheesh !
But don’t hold your breath …..