Bug 11367 - AccelMap.LookupEntry does not fill in the AccelKey
Summary: AccelMap.LookupEntry does not fill in the AccelKey
Status: NEW
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: 2.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-03-23 00:50 UTC by yacadoo
Modified: 2013-04-22 14:50 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Example code (13.59 KB, application/x-zip-compressed)
2013-03-23 00:50 UTC, yacadoo
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 11367 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description yacadoo 2013-03-23 00:50:34 UTC
Created attachment 3685 [details]
Example code

The AccelMap.LookupEntry() method does not return a filled in AccelKey upon successful execution. I have attached an example.
Comment 1 Bertrand Lorentz 2013-04-21 08:46:20 UTC
Thank you for your bug report.

I've committed a fix to git master (which targets GTK+ 3):
https://github.com/mono/gtk-sharp/commit/f14eee3eb

The key parameter must now be passed as an "out" parameter.

I'm not sure this fix can be applied to the gtk-sharp-2.12 branch, as it causes an API change. On the other hand, the method is mostly useless without that change.
Comment 2 Andres G. Aragoneses 2013-04-21 08:54:36 UTC
FWIW Mike Kestner used to say that API breakage was only acceptable when the previous wrong API would crash or be useless.
Comment 3 Mikayla Hutchinson [MSFT] 2013-04-22 10:39:14 UTC
It's not breakage is it? Just addition?
Comment 4 Andres G. Aragoneses 2013-04-22 12:15:41 UTC
Michael, AFAIU, it's not addition, it's a "fixup" entry that makes a method receive a param as "out" instead of default "in".
Comment 5 Mikayla Hutchinson [MSFT] 2013-04-22 14:39:40 UTC
Ah. Would it be possible to generate both versions?
Comment 6 Andres G. Aragoneses 2013-04-22 14:43:47 UTC
Yes, via adding it to the corresponding non-autogenerated partial class.
Comment 7 Mikayla Hutchinson [MSFT] 2013-04-22 14:47:07 UTC
Okay, I think that would be the way to go, plus an [Obsolete] on the broken one.
Comment 8 Andres G. Aragoneses 2013-04-22 14:50:26 UTC
Agreed. Ideally putting the broken one in the non-autogenerated part, so 2.x and 3.x are in sync in regards to fixups.

(Oh, 2.12.x branch doesn't use partial classes, so it would be just adding it to a .custom file.)