I am writing a Go adapter extension for the Test Explorer extension for Visual Studio Code. My extension uses language services from Microsoft's Go extension:
const symbols = await vscode.commands.executeCommand('vscode.executeDocumentSymbolProvider', uri)
However, I have an issue. When I specify extensionDependencies and activationEvents correctly (in package.json), symbols don't initially load (the command returns undefined). If I set activationEvents to * or if I delay for long enough in my activate handler, symbols load. I thought about retrying until the command returns something, but "this file has no symbols" and "there is no symbol provider for this type of document" both return undefined.
Is there a way to delay until a symbol provider has been defined for a specific file extension/language? Waiting for the Go extension to be activated is not enough. I would use GoDocumentSymbolProvider directly, but the extension doesn't export anything.
It looks like it will be possible to add a delay time before your extension is activated. See https://github.com/microsoft/vscode/issues/98083 (Add support to eventually activate an extension on startup). And https://github.com/microsoft/vscode/issues/98990 (Delayed startup activation events).
Will be in v1.46. From v1.46 release notes onStartupFinished activation event:
We now have a new activation event, similar to the already existing *
activation event. The new onStartupFinished activation event should
be used when an extension wishes to be activated sometime soon after
VS Code startup, but not as part of the startup.
However, it is just a hard-coded delay, not based on other events but may still help your situation.
There is a new activation event which looks like e.g. onStartup:1000
or onStartup:5000. This means that the extension wants to be
activated 1000ms or 5000ms after startup. This is very similar to *
activation, but the extension indicates that it can wait a bit.
Related
How to add a pre-draw hook to current context workspace.tools change?
I attempted to get there using bpy.types.SpaceView3D.draw_handler_add(...) which as it runs on every draw, checks if workspace.tools changed, and if it changed, run my callback, but my callback wants to add its own SpaceView3D.draw_handler_add and doing it this way adds it a frame-too-late, leaving the view port undrawn until a user event repaints the screen.
I found this post online
https://devtalk.blender.org/t/update-property-when-active-tool-changes/11467/12
summary: maybe there is a mainline callback new
https://developer.blender.org/D10635
AFWS Jan '20
#kaio
This seem like a better solution. It’s kind of a mystery code, cause I
couldn’t figure out where you got that code info ,but then started
looking at the space_toolsystem_common.py file. kaio AFWS Jan '20
Just realized there might be a cleaner way of getting callbacks for
active tools using the msgbus. Since workspace tools aren’t rna
properties themselves, figured it’s possible to monitor the
bpy_prop_collection which changes with the tool.
The handle is the workspace itself, so shouldn’t have to worry about
keeping a reference. The subscription lasts until a new file is
loaded, so add a load_post callback which reapplies it.
Note this doesn’t proactively subscribe to workspaces added
afterwards. Might need a separate callback for that :joy:
import bpy
def rna_callback(workspace):
idname = workspace.tools[-1].idname
print(idname)
def subscribe(workspace):
bpy.msgbus.subscribe_rna(
key=ws.path_resolve("tools", False),
owner=workspace,
args=(workspace,),
notify=rna_callback)
if __name__ == "__main__":
ws = bpy.context.workspace
subscribe(bpy.context.workspace)
# Subscribe to all workspaces: if 0:
for ws in bpy.data.workspaces:
subscribe(bpy.context.workspace)
# Clear all workspace subscriptions if 0:
for ws in bpy.data.workspaces:
bpy.msgbus.clear_by_owner(ws)
From the Debug Adapter Protocol Specification it is quite clear how to react on frontend changes. For example: when the user selects a frame so the dap backend is getting an event, the user changes a breakpoint, so a SetBreakpointsRequest() is received.
But how to send "insights" to the frontend, for example when the backend recognizes a breakpoint change or a change of active frame by the debugger?
Note: I've directly tried to add them in the backend with the following code - but as long as that was in the debugging did not start and neither output panes nor debugging pane showed any reason.
import * as vscode from "vscode";
var loc = new vscode.Location(vscode.Uri.file(file), new vscode.Position(line,0));
var bp = new vscode.SourceBreakpoint(loc);
vscode.debug.addBreakpoints([bp]);
A debugger adapter can update breakpoints with an event. See https://microsoft.github.io/debug-adapter-protocol/specification#Events_Breakpoint
The event indicates that some information about a breakpoint has changed.
interface BreakpointEvent extends Event {
event: 'breakpoint';
body: {
/**
* The reason for the event.
* Values: 'changed', 'new', 'removed', etc.
*/
reason: 'changed' | 'new' | 'removed' | string;
/**
* The `id` attribute is used to find the target breakpoint, the other
* attributes are used as the new values.
*/
breakpoint: Breakpoint;
};
}
The Breakpoint object contains an id that you can use to reference an existing breakpoint.
A typical scenario for this would be when you start debugging, the code is loaded in your runtime and a breakpoint is automatically moved from a no-code line to the next line with code. This is how the Debug Adapter would signal to the IDE that it needs to update the breakpoint location.
Generally the specification section "Requests" is something that gets initiated by the IDE (usually the user) and the section "Events" is something that gets initiated by the Debug Adapter or the Debugger Engine Backend...
Note, all this is only possible when a debug session is active. If you have some other requirements, that your extension should modify breakpoints and such while there is no active session, or perhaps do something that is not covered by the DAP specification, you will need to implement some extension code and use the vscode.debug API https://code.visualstudio.com/api/references/vscode-api#debug
I'm unable to figure out why WinDBG is in a BUSY state:
Is there a way to find a description?
There is no way to find the exact reason why WinDbg is busy, but you can verify what the last event it was responding to, by using '.lastevent'. However, for your particular case, it is busy looking for symbols and source code for kernel32!CreateFileW. If you have an extension registered for events you would receive change symbol state
IDebugEventCallbacksWide::ChangeSymbolState
DEBUG_CSS_LOADS The engine has loaded some module symbols.
DEBUG_CSS_UNLOADS The engine has unloaded some module symbols.
DEBUG_CSS_SCOPE The current symbol scope has changed.
DEBUG_CSS_PATHS The executable image, source , or symbol search paths have changed.
DEBUG_CSS_SYMBOL_OPTIONS The symbol options have changed.
DEBUG_CSS_TYPE_OPTIONS The type options have changed.
Also check this:
IDebugEventCallbacksWide::ChangeEngineState
Those events are:
DEBUG_CES_CURRENT_THREAD The current thread has changed, which implies that the current target and current process might also have changed.
DEBUG_CES_EFFECTIVE_PROCESSOR The effective processor has changed.
DEBUG_CES_BREAKPOINTS One or more breakpoints have changed.
DEBUG_CES_CODE_LEVEL The code interpretation level has changed.
DEBUG_CES_EXECUTION_STATUS The execution status has changed.
DEBUG_CES_ENGINE_OPTIONS The engine options have changed.
DEBUG_CES_LOG_FILE The log file has been opened or closed.
DEBUG_CES_RADIX The default radix has changed.
DEBUG_CES_EVENT_FILTERS The event filters have changed.
DEBUG_CES_PROCESS_OPTIONS The process options for the current process have changed.
DEBUG_CES_EXTENSIONS Extension DLLs have been loaded or unloaded. (For more information, see Loading Debugger Extension DLLs.)
DEBUG_CES_SYSTEMS A target has been added or removed.
DEBUG_CES_ASSEMBLY_OPTIONS The assemble options have changed.
DEBUG_CES_EXPRESSION_SYNTAX The default expression syntax has changed.
DEBUG_CES_TEXT_REPLACEMENTS Text replacements have changed.
I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.
As of Build 8201.2025 there has been an unexpected change to the order of events when loading a VSTO addin with a Ribbon in Word.
Using Office version 16.0.8067.2115 or older. When loading the addin the following order of events is observed (as has always been the case).
Ribbon_Load event
ThisAddin_Startup event
Using Office versions 8201.2025, 8201.2064 or 8201.2075 or newer the order of events is reversed which is an unexpected breaking change.
ThisAddin_Startup event
Ribbon_Load event
I have created a simple VSTO Addin using a Visual Designer Ribbon to demonstrate the issue.
>
Public Class Ribbon1
Private Sub Ribbon1_Load(ByVal sender As System.Object, ByVal e As RibbonUIEventArgs) Handles MyBase.Load
System.Diagnostics.Debug.Write("Ribbon1_Load event called.")
'Pass the Ribbon to the Addin.
ThisAddIn.MyRibbon = Me
End Sub
End Class
Public Class ThisAddIn
Public Shared Property MyRibbon As Ribbon1 = Nothing
Private Sub ThisAddIn_Startup() Handles Me.Startup
Debug.Write("ThisAddin_Startup Called")
If (MyRibbon Is Nothing) Then
Debug.Write("MyRibbon is nothing - the ribbon was not captured.")
Else
Debug.Write("Ribbon captured successfully.")
End If
End Sub
End Class
Debug output for 16.0.8067.2115 32 bit
[7772] Ribbon1_Load event called.
[7772] ThisAddin_Startup Called
[7772] Ribbon captured successfully.
Debug output for 16.0.8201.2075 32 bit
[13556] ThisAddin_Startup Called
[13556] MyRibbon is nothing - the ribbon was not captured.
[13556] Ribbon1_Load event called
I have posted this up on the Microsoft Support forums however they have stopped responding and since released this version to the Current office channel I need help from the dev community.
Has anyone found a successful workaround? This change of timing is causing alot of problems with how we initialise. It would be ideal for Microsoft Support to provide a solution or workaround until they investigate this bug.
I always got Ribbon_Load before ThisAddin_Startup because I use Ribbon XML. Ribbon UI allow less controls ... As the both are "entry" points, I suggest you to use only Ribbon1_Load at startup. Or, if you use the Ribbon XML model and you want the very very first entry point, try its constructor
I am not feeling that issue as a bug, to make Word fast many processes are asynchronous. So, in my opinion, the first of ThisAddin_Startup or Ribbon1_Load to start can accidentally change depending on many factors: System performances, Word started alone, Word started via a doc ...
Hope this helps someone! We used the following workaround successfully to work around the changed office load behavior.
Within ThisAddIn_Startup loop until the Ribbon load event has fired and the ribbon is captured.
While m_oRibbon Is Nothing
If (timeWaited >= MAX_WAIT_TIME) Then
Exit Try
End If
Threading.Thread.Sleep(50)
timeWaited = timeWaited + 50
End While