Bug 8245 - Help on unresolved types should perform a search
Summary: Help on unresolved types should perform a search
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Shell ()
Version: Trunk
Hardware: PC Mac OS
: --- major
Target Milestone: ---
Assignee: Mike Krüger
Depends on:
Reported: 2012-11-06 11:04 UTC by Miguel de Icaza [MSFT]
Modified: 2012-11-27 01:33 UTC (History)
3 users (show)

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

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 on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Miguel de Icaza [MSFT] 2012-11-06 11:04:40 UTC
It seems that context-sensitive help (On Mac bounds to command-alt-shift-/) works as long as the type can be fully resolved, and takes me directly to that type or method.

For example, hitting it in WriteLine here works:
Console.WriteLine ();

But it fails if it is unable to resolve the statement, for example:

Or if the type does not exist.

In those cases, we should instead invoke MacDoc with an option to search for the word under the cursor.
Comment 1 Miguel de Icaza [MSFT] 2012-11-06 11:05:36 UTC
Some context, users can not get this to work, likely because the type does not resolve sometimes:

Comment 2 Mikayla Hutchinson [MSFT] 2012-11-06 11:57:11 UTC
Surely we should also be able to do a "best guess" resolve in that case?
Comment 3 Miguel de Icaza [MSFT] 2012-11-06 12:00:41 UTC
Let us add a --search=TERM option to MacDoc.

Jeremie, that is in your plate.

Mike, you should make it so that if we can not resolve, we invoke the help with that.
Comment 4 Mike Krüger 2012-11-07 00:34:40 UTC
Implemented in uirefresh.

@mhutch: I think that case only happens when an assembly ref is missing - why wouldn't a user just use the resolve feature instead?
(at least after we integrate the context sensitive hints)
Comment 5 Miguel de Icaza [MSFT] 2012-11-07 15:32:28 UTC
Reopening, the ball is now on Jeremie's court to implement --search=TERM
Comment 6 Jérémie Laval 2012-11-19 07:54:32 UTC
Implemented on MacDoc side.

The MonoDevelop side doesn't work though, if the member is unresolved, SourceEditorWidget::MonodocResolver is never called with the contextual search shortcut.
Comment 7 Mike Krüger 2012-11-26 02:06:39 UTC
Should work now.
Comment 8 Jérémie Laval 2012-11-26 08:37:20 UTC
Still not calling the right method.
Comment 9 Mike Krüger 2012-11-27 01:33:22 UTC
Which use case do you have ?

It works for me on the console.writeline case - either it searches for WriteLine or Console.

The method called is HelpOperations.SearchHelpFor
Comment 10 Mike Krüger 2012-11-27 01:33:54 UTC
btw. are you trying ui-refresh or master ?