Okay, got folding working off the parser. As a bonus it makes a bunch of code gone from the TextChanged handler, and foldings will only be evaluated when idling
I need to find words with the following pattern in one go:
started to [infinitive verb]
began to [infinitive verb]
started [progressive verb]
began [progressive verb]
For example:
started to arise
began to arise
started arising
began arising
Right now I am using two step method.
find the fir...
@MathieuGuindon That looks really good already. Do you already have an idea how we can sync the editor back into the VBE without shooting ourselves in the foot.
how do I use Application.WorksheetFunction on a specific worksheet within a workbook that I've opened in my VBA code?
I'm trying to use the Match() function and it's giving me an error, and I think it may be because I'm using myOpenedWorkbook.Application.Match("searchstring", "range",0), yet it may not be looking at the specific worksheet that I want it to be looking at...
oh, nope. wrong error. I'm getting the all seeing 1004 with this description: Unable to get the Match property of the WorksheetFunction class
@M.Doerner good question.. I was thinking of making it a command at first, and then it could probably be invoked during the full parse. But before that there's also the editor VM that needs to no longer be a hard-coded "Module1", and it would be nice to get Dragablz to work too; then we have an editor shell!
ha, having the members figured out with the parser means the "Members" dropdown can show all the members... is this a good idea?
Need to figure out how Antlr recovery works; IIUC block completion could actually happen as the parser discovers that an End Sub token is missing, and it can inject it into the token stream, and then the modified code can overwrite the document. Could probably also work for turning function into Function
oh, so far there is no parsing whatsoever happening outside the RD3 editor, so no problem there! and yeah, it's going to have to happen via file import. Need to mind VB6 here.
not sure about reacting to changes outside the editor, other than syncing code content with the VBIDE
rule of thumb, the fewer VBIDE interactions, the better :)
We will need the declarations for all the other code that is not open for multiple reasons. For one, we need them for the references. In addition, we need them for unit test discovery and code inspections for the entire project.
It would be a giant step back if you had to open every module to see all your problems.
Also, without the other declarations, there would be nothing to power the code explorer.
Oh we'll absolutely parse everything and have all the declarations! But I think we probably should take the easier route of only reacting to events and commands within the editor, i.e. if you flip back to the VBE and edit a code pane or add or rename a module, we'd only pick it up on the next full parse, as opposed to in direct response to that event
Unrelatedly, it would be funny if we had a UserForm designer made in WPF
I mean, WPF rendering a designer for MSForms, running hosted in a WinForms user control, hosted in a native toolwindow. #FullCircle
OK, let us start with very little reaction to the VBE and maybe increase it later as an extra.
I am just thinking whether we could hold a directory with exported files in sync with the VBE. That would make picking up the changes from the outside somewhat easier. But I guess that is a later problem.
I like that... needs a setting so default goes to temp files, and when activated we could track folders, and make it work with @Folder subdirectories from the start!
VBA Rubberducking
VBA Rubberducking