I can do VBACodeStringParser.Parse(sourceText, t => t.startRule().module().moduleBody()); and the compiler allows me to do that since moduleBody is contained in module is contained in startRule.
The only way I see presently to get the annotations is to drill down from t => t.startRule().module().Foo(). ... Bar().annotationList() to end up with the list of annotations.
I'm stuck on the idea of a tree then and how to git what I want.
~.~
MDoerner gave me the suggestion:
> You could avoid all the text search based problems from my comments by looking for contexts of type VBAParser.AnnotationContext only and using the annotationArg child of the first annotationArgList child to identify the folder.
It's out there! It's been 560 days since the first commit and I probably should have released a long time age, but goodness it feels good to get this journey started. A package manager for VBA, it seemed far-fetched at the time, but it works! #SpreadsheetDay https://twitter.com/vbablocks/status/1052746324700004358
@M.Doerner I just want to check in with you - I'm trying to fix the ghost bug with Access and I want to first rule out the possibility of a dangling COM reference preventing proper shutdown. I've been reviewing the contents of COM safe, and I'm finding that a number of GC'd SCW are coming from various commands. For example, FindAllReferencesCommand has this in its FindTarget and FindCodeTarget:
@IvenBach R# is warning about some string comparison being culture-specific, because no comparer is specified. You can shut it off using a StringComparison enum parameter (use a method, not an operator), I think that will prevent matching a string like "Földer", if the user is using a culture where "ö" equates "o".
This seems to be missing a using. Furthermore, the FindTarget already has the _vbe.ActiveCodePane in a using. So I modified the FindCodePaneTarget to take a ICodePane parameter and moved it inside the using block declared in the FindTarget method.
There are other examples, too. FormRefactorRenameCommand has this: var component = Vbe.SelectedVBComponent; which wasn't in a using block. I thought maybe it was exempt because of the project repository but when I followed the code, I could not see it being used with the project repository implicitly, so I changed that to a using block.
Hi! I am sure this has come up but my Google-Fu is failing. If I have an open windows explorer Save As window and I have found its handle, how do I send the file name I want to it?
Or is there a better way? For complicated reasons I am having to use SendKeys to save a pdf from internet and can get as far as this window.
Basically, I can't interact with the page via DOM as all useful stuff is in Shadow-Root so have had to resort to Chrome shortcuts.
Thanks. Still hasn't fixed the ghost process yet but I'm going forward on the assumption that the fix might required all those to be fixed anyway. The serialization of COM safe really helps to see where it's coming from.
@this There are only two cases where a disposal is not necessary. The first are rewrapped wrappers, which we use only in two places. (For these, disposal is basically a no-op.) The second are the wrappers received from the provider. These must only be disposed by the provider itself.
@M.Doerner OK, that is what I understood, too. I was hesitant because I remember months ago when you introduced COM safe, I flagged some, mainly in commands if I remember, as need disposing but you said those cases were not necessary. But it was so long ago and circumstances may have been different.
But it sounds like the examples I provided are necessary to change, so I will continue finding any other places from the serialized log to see where else may be leaking SCWs.
i was going through my DRM free copies of the games he was interested in
@IvenBach it looks like i also have access to a pertttttty large library of DRM free games that includes the first trine as well, so i can get you trine 1 and 2
ok. its gunna take a day for my google drive's space to upgrade anyway
that and for some reason i cant remote my machine right now, i assume it went to sleep
probably because i turned off my MC server
so, for now, im just going to grab trine 1 and 2, and braid for you
if you like any of the rest i saw on htere, i'll provide you with installer links
i probably could direct link you to the files, but i figure that its going to be more stable if i just give you access to the google drive folder i plan on putting them in
@M.Doerner So the VS Code ANTLR debugger is really easy to set up, but it expects a Java compatible grammar file. Is that what you're using in Eclipse?
However, there is disclaimer on the github repo that predicates do not work. However, I do not know whether that is restricted to predicates using external code.
My Java grammar version is from a time when none of the two had entered the grammar.
Based on what I saw in the configuration, I'm guessing it's predicates using external code, but I won't be able to verify that until ANTLR stops complaining about it not being a valid grammar file.
I'm obviously still going to use it for a grammar editor, but the debugging tools would be a nice bonus.
Good. In eclipse, it was possible to just paste in the text and I think I got away with only a subset of the grammar, since I was more interested in understanding the shape of the parse tree back then.
I only remember that when I tried to start at the top level rule, it complained about missing attribute.
since I was only trying to analyze a procedure, I went for moduleBody instead and that sufficed for my need. Did not feel a need to argue with Eclipse at that time.
BTW, that was last year - I don't remember if there has been changes to the attribute rule in the intervening time.
FML
using (var activePane = Vbe.ActiveCodePane)
{
if (Vbe.ActiveCodePane == null || activePane.IsWrappingNullReference)
{
return false;
}
target = _state.FindSelectedDeclaration(activePane);
}
var callStmtContext = reference.Context.GetAncestor<VBAParser.CallStmtContext>(); is taking the ParserRuleContext in reference.Context, and finding the ancestor node of the type VBAParser.CallStmtContext.
Using your example Comintern I've var fooAnnotationList = ParserRuleContextExtensions.GetDescendents<VBAParser.AnnotationContext>(); is red lined and I'm so confused. I've confirmed AnnotationContext is a descendent of ParserRuleContext.
var fooAnnotationList = somevariable.GetDescendents<VBAParser.AnnotationContext>();
<Foo> is the type argument for the generic. this ParserRuleContext context is the parameter.
You can explicitly pass it with this syntax: GetDescendents<VBAParser.AnnotationContext>(somevariable);
Or you can use the extension method syntax: somevariable.GetDescendents<VBAParser.AnnotationContext>();
Those 2 lines of code are functionally identical.
That's what the this keyword means in the signature - it implicitly passes the object it's being called on as the parameter context. Just syntactic sugar.
@Comintern Please note the affixed warning from General Surgeon -- too much sugar can lead to diabetics, cancer, obesity in your code.
@IvenBach be also aware that there are type constraint, too. I don't know if ANTLR makes use of them, though. In fact that'd be another reason to not use T as the identifier since it won't communicate any constraints that may be placed upon the generic type.
Forgive me if it seems like I'm continually asking for handouts on this. I'm add my thought process and what I'm attempting to show I'm putting in effort to figure it out. It's just #ThisIsHard for me being new to all this.
Trying the cast ((VBAParser.AnnotationContext)result.parseTree).GetDescedents<...> barfs with an error.
2018-10-19 10:16:40.5807;ERROR-2.2.6866.18430;Rubberduck.UI.CodeExplorer.Commands.ImportCommand;System.InvalidCastException: Unable to cast object of type 'StartRuleContext' to type 'AnnotationContext'.
at Rubberduck.UI.CodeExplorer.Commands.ImportCommand.OnExecute(Object parameter) in C:\Users\cpaustell\Source\Repos\Rubberduck\Rubberduck.Core\UI\CodeExplorer\Commands\ImportCommand.cs:line 104
at Rubberduck.UI.Command.CommandBase.Execute(Object parameter) in C:\Users\cpaustell\Source\Repos\Rubberduck\Rubberduck.Core\UI\Command\CommandBase.cs:line 47;System.InvalidCastException: Unable…
The tuple (IParseTree parseTree, TokenStreamRewriter rewriter) coming from Parse
Converting it to var fooAnnotationList = result.parseTree.GetDescendents<VBAParser.AnnotationContext>();
Error CS1929 'IParseTree' does not contain a definition for 'GetDescendents' and the best extension method overload 'ParserRuleContextExtensions.GetDescendents<VBAParser.AnnotationContext>(ParserRuleContext)' requires a receiver of type 'ParserRuleContext'
@MathieuGuindon / @M.Doerner / @Comintern I hate to ask but if any of you could give the serialize PR a quick look over just to be sure I have not missed any more boneheaded mistakes, I would appreciate that. :)
@Comintern var fooAnnotationList = (VBAParser.AnnotationContext)result.parseTree.GetDescendents<VBAParser.AnnotationContext>(); produces an error as well.
as does (VBAParser.AnnotationContext)(result.parseTree)
I think VS is marking the parenthesis as redundant too.
tbh it's hard to visualize the SCP just by looking at the code. I think you'll get more feedback once merged and hopefully that helps get you over the roadblock at the present.
the important thing is that killswitch actually works, yes? ;-)
@MathieuGuindon I'm with @this on that. I'm good with merging too - it will help identify anything else that needs to be addressed (that's what pre-release is for).
var fooAnnotationList = (Antlr4.Runtime.ParserRuleContext)(result.parseTree).GetDescendents<VBAParser.AnnotationContext>(); has a compile time error whereas var fooAnnotationList = ParserRuleContextExtensions.GetDescendents<VBAParser.AnnotationContext>((Antlr4.Runtime.ParserRuleContext)(result.parseTree)); doesn't.
Testing with second version to see if it throws an error.
Hmm I think there are a couple review comments from @Vogel612 that I haven't addressed yet. Not sure what to do about the null-return though - the basic mechanics of it is that it either returns a CodeString with the new info, or null in which case the service knows to let the keypress through
@MathieuGuindon I'm not sure I agree that the mechanics there are wrong. Returning null for a "failed" request is a common enough idiom that I don't think is makes sense to change it. I'm also not sure how else you would accomplish that without introducing state somewhere it arguably wouldn't belong.
i don't follow - if you create a Try* method, it implies it's doing a try/catch which may throw within the method (and return null in the ref and false as the result)?
so public abstract CodeString Handle(AutoCompleteEventArgs e, AutoCompleteSettings settings); needs to become public abstract bool TryHandle(AutoCompleteEventArgs e, AutoCompleteSettings settings, out CodeString result);
actually I'm not using any settings in the SCP handler, and the smart-concat handler only uses them to know whether or not to bail out (for now) ...I think I can eliminate the parameter.
although, it'll probably end up being re-added when more SCP options are added
but yeah right now it's YAGNI
also, about settings - should I clean up the old block-completion settings (which are currently no-op) now, or do that in the block-completion PR (which will need settings)?
the settings page for AC is confusing AF right now
private static readonly IEnumerable<SelfClosingPair> SelfClosingPairs = new List<SelfClosingPair>
{
new SelfClosingPair('(', ')'),
new SelfClosingPair('"', '"'),
new SelfClosingPair('[', ']'),
new SelfClosingPair('{', '}'),
};
The moduleOption has 4 options it can match (pun not intended). The labels allow you to refer to those specific matches instead of only "moduleOption".
> Closing this as possible further enhancements are not detailed in this ticket, and the main work is done. Other enhancements can be brought up after the feature has been in use.