A dancer for money, I'll do what you want me to do

[venta]

Help me, interwebs, you're my only hope...

Yesterday, my code compiled.
Today, it does not.
Specifically, the back-up I took when I stopped working last night compiled yesterday and does not today. This has happened to me before with the same (.NET, Managed C++) application - along comes Patch Tuesday and suddenly the formerly working code won't compile any more. Last time the only solution seemed to be rolling back the update.

I have this rather wormly-looking line in my app:

System::Windows::Forms::Keys keycode = (System::Windows::Forms::Keys) System::ComponentModel::TypeDescriptor::GetConverter(System::Windows::Forms::Keys::typeid)->ConvertFromString("F3")));

[*]

If you have an M$ key code, then getting a string representation of that is dead easy (keycode.ToString()). When you have the string, getting the key code out again requires, as far as I can tell, the above horror (cribbed from MSDN).

It could be made less horrible by whipping out all the namespace nonsense, but I've left that in for now for the avoidance of ambiguity.

Yesterday, it compiled, but 18 Windows updates later, and I get this:

1>c:\antix\svn\gdk_docs\tools\config\regapp\regapp\Form1.h(8636) : error C2248: '<PrivateImplementationDetails>{26B74265-9CDF-44A5-8878-90A25F9512EE}::__StaticArrayInitTypeSize=29' : cannot access private class declared in class '<PrivateImplementationDetails>{26B74265-9CDF-44A5-8878-90A25F9512EE}'
1> c:\windows\microsoft.net\framework\v2.0.50727\system.dll : see declaration of '<PrivateImplementationDetails>{26B74265-9CDF-44A5-8878-90A25F9512EE}::__StaticArrayInitTypeSize=29'
1> c:\windows\microsoft.net\framework\v2.0.50727\system.dll : see declaration of '<PrivateImplementationDetails>{26B74265-9CDF-44A5-8878-90A25F9512EE}'
1> This diagnostic occurred while importing type 'System::ComponentModel::TypeDescriptor ' from assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
1>

I don't understand that error message. It seems (to me) to be telling me something is private, but (a) it wasn't yesterday (b) the docs for all the relevant parts haven't changed and (c) I'm not entirely sure what exactly it thinks is private anyway.

Googling for the update numbers and the keys in the error message hasn't really turned up anything (though my google-fu is occasionally very weak). At present, I don't feel I've got much option but to roll back the updates and hope for the best.

I would, however, like to know what's going on and how to fix it. If anyone has the dimmest of lights to shed on this, I'd be most grateful.

[*] It doesn't really say "F3", it usually takes the text field of an object. I've just put a static string in there to try and reduce possible sources of error. So don't go suggesting I replace the entire string with "(Keys) 0x73"!


Update: Uninstalled one of the several .NET updates, rebuilt, and it compiled fine. Re-installed the update... and it compiled. Must have been a dodgy installation, or something getting out of synch in ways I don't understand.

Comments

[bateleur.livejournal.com]

I don't speak .Net so this might be complete bobbins, but should you in fact be using KeysConverter for this?

[venta.livejournal.com]

Sadly, I don't speak .NET either, in any meaningful sense. I started with KeysConverter yesterday, but couldn't find any way of getting it to do anything sensible (MSDN has no example code, either) and eventually moved onto the nastiness quoted above.

[bateleur.livejournal.com]

Oh, OK.

In which case I shall just blink in confusion and wish you good luck.

[venta.livejournal.com]

I'm approaching from the update-rollback direction for now, since I haven't managed any productive work yet today!

[chrisvenus]

I do speak .NET but have never done much winforms stuff. That having been said I looked at the keyconverter class in a decpompiled form (thanks Reflector) and it really does look like it should do what you want. It looks like it should take a string and do a lookup first against a set of static things, then try to parse it as an enum value against keys and if that fails throw an exception. It also copes with multiple keys split by "+" by the looks of things.

The context and culture parameters of "ConvertFrom" only seem to be used if the "value" is not a string so you shouldn't need to care about them.

FWIW I have no clue about why it suddenly stopped working. I'm assuming that one of your updates was a .NET Framework update?

[venta.livejournal.com]

I've found several references online to the idea that you shouldn't use KeysConverter directly, but should use TypeConverter. Not in the official docs, though.

I tried doing this instead:


KeysConverter keyConverter = gcnew KeysConverter();
key = (Keys)keyConverter.ConvertFrom("F3");

.. but that fails to compile, because apparently there is no copy-constructor for KeysConverter. If I could work out how to use KeysConverter, I'd give it a try :(

[onebyone.livejournal.com]

How many keycodes are there? Could you roll your own reverse lookup just by looping over them all calling ToString() and stuffing it in a dictionary? Not very satisfactory, but then by the sounds of it neither is MSDN's suggestion.

[venta.livejournal.com]

Well, the line quoted above works fine, as far as I can tell, so rolling my own seems a bit peverse. I'm not sure exactly how many keycodes there are (let's assume at least as many as there are keys on the keyboard).

There are also Issues, because some codes are defined to be mapped to different things - the "," key comes up with the name "OemComma" because I believe some keyboards use that keycode for something else, so I don't know it'd be a trivial task to get something which worked on every keyboard (rather than just on mine).

[onebyone.livejournal.com]

"works fine, as far as I can tell"

Apart from not compiling, you mean? ;-p If something has become private in the new version of the assembly, will it run on systems which have been updated?

Fair enough about the multiple mappings, though: if both "," and "OemComma" map to the same keycode, then there is no such thing as the reverse mapping I propose.

[venta.livejournal.com]

Apart from not compiling, you mean?

I'm assuming that the installtion of the update failed somehow, since rolling back and re-applying the update fixed the compilation issues, implying that the privacy of all classes concerned hadn't actually changed.

[onebyone.livejournal.com]

Oh right, I missed your update.