As I've mentioned a couple times now, the SelectionRange is inclusive, meaning that every date between MonthCalendar.SelectionStart and MonthCalendar.SelectionEnd is selected. Unless there's some undocumented feature of the MonthCalendar or you've extended and overridden its behavior, this is how the MonthCalendar works - a single date range can be selected.
Now, if you want to track every selection the user makes, handle the MonthCalendar.DateSelected event and add the range from DateRangeEventArgs.Start and DateRangeEventArgs.End to an ArrayList or something, which you can later use ArrayList.CopyTo to create an array from the list.
I've got it now and am only posting it here now for posterity. I must have been pretty tired when I worked on it last because it was right there as obvious as could be. I swear I went through the docs on the MonthCalendar class about 5 times and didn't see what I wanted, but NOW I see there is a property BoldedDates which returns to me an array of DateTime of all the dates that are bolded. Which is EXACTLY what I was trying to get.
Why it was so hard, I don't know. Like I said...I must have been tired...it was late last Saturday or Sunday night when I played with it last.
There are only 10 types of people in this world....those that understand binary, and those that do not.
You never said bolded dates - those are different from selected dates, hence even the different property names. If you had specified that before, I could've told you immediately; of course, if you had looked at the class members like I mentioned you should do before - i.e., read the documentation - it should'be been obvious.
There is a big difference between bolded and selected dates, though.
No, there is currently nothing in the .NET base class library that deals with NTFS permissions. There may be some third-party libraries out there and I'm sure "Longhorn" will introduce such encapsulation, but you either have to use the NTFS APIs or try to write a zero-byte file to the directory and catch any exceptions that are thrown.
For more discussion about alternatives, please click the "Search Comments" link above. We have covered this in the past. There are also a few articles here on the CP web site. Use the search text box toward the top of the page (below the logo).
By P/Invoking the functions you need. See DllImportAttribute for more information. It would also be best to encapsulate this into a nice class or classes. It will give you and your clients a better object-oriented approach to dealing with CAB files.
IntPtr. You should also read about interoperability in .NET in the .NET Framework SDK, as well as understand what the intrinsic types are. In .NET, this is pretty easy because the bit size is part of the Type name, like Int32 is 32 bits. Knowing what the types are in the Win32 APIs isn't always so easy, but looking at the data types in the Platform SDK at http://msdn.microsoft.com/library/en-us/winprog/winprog/windows_data_types.asp[^] can help, especially if you have the Platform SDK installed so that you can search the headers for the typedef (personally, I use gvim.exe (Graphical Vi IMproved) with tag files created by ctags.exe).
I have a .net/C# project that prompts the user for a couple of parameters during installation. These parameters are then passed to an installer class as a custom action which validates this data before letting installation complete.
I am now trying to do a silent installation deployment of the application and want the user to type in these parameters as command line arguments. I have played around with msiexec.exe and how to install .msi files under silent mode. That being said, I cannot figure out how to pass command-line data to a custom action that is an installer class (!) Before I was just using the CustomActionData property and feeding in the parameters that way - but having trouble now trying to do this from the command line. Anyone have any advice? Thanks.
Add a secure public property (all capital letters and added to the semi-colon-delimited list of the SecureProperties property) to your installer project and use that public property (using the square brackets, [PROPERTY]) as the value for the param(s) of your Installer class. A user can then use msiexec.exe /i ... Package.msi /PROPERTY=Value. I use this for our installation and it works great. You should also consider giving this property a default value as well.
The only real problem is that the Windows Installer project for VS.NET is very lacking. You'll either need to use a real development environment like Wise for Windows Installer or the very expensive InstallShield DevStudio, or download the Windows Installer SDK from http://msdn.microsoft.com/platformsdk[^] and install the Orca.msi package to obtain Orca - perhaps one of the best tools for MSI developers and AD administrators! Just open your compiled MSI package in that and add the property to the Property table post-build. You can use that same property name in your Custom Action command line for your Installer class at design-time, though.
I do an encryption with hashing and now try to check itfor myself so I show output of encyption in my console application ,then I replcae one of characters with another one to check changing the string and my hashing mechanism get it,for example replace 2 with 1.But in this situation I get run time error at the line which I use FlushFinalBlock() for my decryptor stream. Any suggestion?
You should be transfering this data as base64. See the FromBase64Transform and ToBase64Transform. There should also be some sample code in there, too. Basically, the plain text and cipher text is run through these transforms which encodes and decodes the data using base64 transforms. This is what most cryptographic providers use as an encoding when transferring cipher text. Converting bytes to strings like you are is not a standard encoding so the cryptographic transforms won't understand it.
If you're changing the cipher text it shouldn't decrypt. What's the point of encryption, then? Throwing an exception is what should be happening in some cases, and "Bad data" sounds about right. I got that once or twice when testing my XML Digital Signatures sample code to make sure that changing the signature digest invalidated the signature.