This is about VBScript, but looks to be pretty useful for analysing p-code and the VM interpreter - I haven't fully read it yet, or played with the GitHub repo, but I'm confident there'll be stuff of use to RD - Delving deep into VBScript
> The CScriptRuntime class contains all information about the state of the interpreter: local variables, function arguments, pointers to the top of the stack and the current instruction, plus the address of the compiled script.
> Microsoft engineer reports dated 1999 and 2004 that shed some light on the p-code. There was enough information there for me to fully reverse-engineer all the VM instructions and write a disassembler!
nope. the 'pcode' they are referring to in VBScript is most similar to VBA/VB6 execode. In VBScript you've got circa 100 opcodes. In VBA/VB6 you've got circa 1000 opcodes.
@WaynePhillipsEA haha. I remember reading somewhere that there's nobody left at MS who knows how it actually works. When their engineers do need to touch VBA, they rely on the APIs, and binary serialisation takes care of itself.
@WaynePhillipsEA I know, but even recent additions haven't been implemented as cleanly as earlier ones. Some new keywords aren't as robustly restricted in terms of how they can be used. I forget a specific example right now.
Version 2.2.0.3468 OS: Microsoft Windows NT 10.0.16299.0, x64 Host Product: Microsoft Office 2016 x86 Host Version: 16.0.4666.1000 Host Executable: MSACCESS.EXE
I restarted access and restarted my code inspection again:
This is the log after ~5 minutes: [RubberduckLog.txt](https://github.com/rubberduck-vba/Rubberduck/files/2162920/RubberduckLog.txt)
Version 2.2.0.3468 OS: Microsoft Windows NT 10.0.16299.0, x64 Host Product: Microsoft Office 2016 x86 Host Version: 16.0.4666.1000 Host Executable: MSACCESS.EXE
I restarted access and restarted my code inspection again:
This is the log after ~5 minutes (the memory consumtion is ~ 600 mb): [RubberduckLog.txt](https://github.com/rubberduck-vba/Rubberduck/files/2162920/RubberduckLog.txt)
I've updated RD today (from a build a few weeks old to 2.2.0.3468-pre) and now on every launch, RD notifies me that Rubberduck version 2.2.6672.23088 is now available! Would you like to review the release notes now? [Yes/No]
> According to the log, the culprit is the ObjectVariableNotSetInspection ...
The code for that inspection iterates over the references between different User modules and thus it's runtime in the worst case is exponential in the number of user modules. That is ... not ideal.
> According to the log, the culprit is the ObjectVariableNotSetInspection ...
The [code for that inspection](https://github.com/rubberduck-vba/Rubberduck/blob/next/Rubberduck.CodeAnalysis/Inspections/Concrete/ObjectVariableNotSetInspection.cs) iterates over the references between different User modules and thus it's runtime in the worst case is exponential in the number of user modules. That is ... not ideal.
obtw: the Resolver logs codesnippets... we should be upfront about that, because corporate overlords might try to sue our backsides off, when they notice
But if you had a If block or Select Case True block and branches depends on the TypeOf xxx Is yyy, a Nothing would always come up as true and thus fall through to the first branch, making all other branches unreachable under that condition.
> My bad. I never updated the website build with 2.2.0, so it's an old debug build up there. There's no bug, just the version-comparison logic falls apart if a non-release build is deployed to the website. I just need to overwrite the file with the actual 2.2.0 build and it'll fix itself. I can do that tonight.
> The parser is meant to support scenarios where we need to work with code that are still up in the air. The parser is totally disconnected from the main parser and takes in a `string` that only needs to represent a minimally valid code module body and builds a valid parse tree.
This can be used for example, in code preview, so that rewriting can be handled using the rewriter API for example.
@Duga If Mat ends up using it in AC, he's going to want the speed of SLL. OTOH, the try won't help. Maybe support overloaded constructor so that by default we try SLL then LL (just like the normal parser), but if explicitly specified, we can skip the try and just parse in that mode. However, the parser will throw an error in all cases, so the calling code has to have a try block while constructing the parser.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=h1) Report > Merging [#4153](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/debf4a6bc809b79fa70428de598b6913b068905d?src=pr&el=desc) will **increase** coverage by `0.02%`. > The diff coverage is `70.97%`.
> * I opened my project * Navigate to a codefile (a Form). It does not matter if I use the Rubberducks modul-explorer or the built in one * uncomment a line * write "Call ZFormHelper." => the autocompete list opens * choose "Bildobjekt" as a function * tried to write "(" to continue => access crashes
This is the log: [RubberduckLog Crash.txt](https://github.com/rubberduck-vba/Rubberduck/files/2163621/RubberduckLog.Crash.txt)
I restarted access several times but I crashed every time I
There's a bug in the autocompletion (exact repro steps still not confirmed though) that makes inline completion crash the process (unhandled off-by-one error, most likely).
You can disable `(`, `{`, `[` and `"` autocompletion to remove the possibility for this bug to happen.
I wrote the below code to make sure account numbers (accounting), which are numbers, are strored as text in the range. Replacing r.value by r.text does not seem to work on whole ranges, so I need to loop. Any better idea ?
Sub num2text(r As Range, Optional keepFormat As Boolean)
'change numbers ...
> Tagging with difficulty 01 because no prior knowledge of how Rubberduck internals work is needed for implementing this - however it does require some experience with WPF and styling: we need these font sizes / styles in a centralized place, so that the UI can be consistent across the board.
@M.Doerner an option is to maintain a standard code module that is auto-regenerated. That's what I do when I need to enumerate a subset of private types or maintain an enum to some external resource (e.g. a table)
> In the use case the parser was originally developed for, I had no need to support the preprocessor directives. That said, anyone else is welcome to enhance it to handle those other cases.
> The last commit allows for explicit mode which also reduces the overhead as when we explicitly specify a mode, there is a one less try block. The calling code, however, still needs to have a try/catch block to handle any exceptions returned by the ANTLR parser. It retains the default behavior of mirroring the main parser, trying w/ SLL then fallbacking to LL mode. When the mode is explicitly specified, there is no fallback at all. That may or may not offer some performance improvements for
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=h1) Report > Merging [#4153](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/debf4a6bc809b79fa70428de598b6913b068905d?src=pr&el=desc) will **increase** coverage by `0.04%`. > The diff coverage is `85.71%`.
Microsoft (124,000 active employees worldwide) has a system for rewarding non-employees, the "Most Valuable Professional".
With apparently 3,024 active MVP worldwide, that's very few people compared to how many devs Microsoft loves.
I'd like to know if MVP people, who are kind of non-employees ...
In the specific case of Access VBA project. It has to reference members of Excel.Application. Seems to me that the Range is not a member of the Application object
@MathieuGuindon The reason Range fails is because the instance of Excel that is implicitly created, is started without any workbooks open, so the Range call fails with exactly the same error as if you try it in Excel without any workbooks open. But try an Excel global like Workbooks from Access, and it does work: wbkCount = Workbooks.Count
You also end up with a hidden copy of Excel as a result of the global call.
^ found by googling "globals vba implicitly created" and the RD github issue is in the top 3 results.
@PeterMTaylor it depends. For calls that involve the creation of an App like Excel, probably yes, but accessing a constant, or creating an object that doesn't involve an App creation, probably not
@PeterMTaylor eg. Scripting Runtime has Global variables, but even if it had some global classes/methods, it wouldn't really be creating an application like the Excel calls are. It's probably still better practice to be explicit though, and probably faster too.
> Currently, the organization of the parser is kind of a mess. Too many things are interwoven that do not belong into the same place and things are done in multiple places although they could be done in one place. Examples can be found in multiple places:
1. The parser does not properly separate getting the code and getting the token stream from the code: both happens in `RewriteAndPreprocess` and in the `AttributeParser`. 2. The preprocessing logic is duplicated in the `AttributeParser`, w
VBA Rubberducking
VBA Rubberducking