@WaynePhillipsEA I haven't looked at it yet. I've been working on serializing FRM/FRX to XML... Partly to get the control ProgId/ClsID of controls (which ITypeLib will solve), but also to make UserForm changes human-readable in source control, and to make conversion to/from .NET/VB6 easier.
@ThunderFrame I forget what the data type was, but reading the documentation for it said that only 1 is returned even if the selection type is multiple.
Getting selected testS to run is something I need myself. Once I get time tomorrow I'll look at having a go at it and trying to implement it.
@WaynePhillipsEA interestingly, the VBE's object browser represents those short-form properties differently from the long-form properties. But IIRC, VBA exposes public variables in class modules as both a getter and a letter/setter.
@mansellan Hi - I certaibly did. Hope yours was good too.
@ThunderFrame what you refer to as short-form properties, is just how properties are always represented in a dispinterface. You'll probably find that the VBE is switching to the normal vtable based interface (which requires some magic in ITypeInfo). Note that the normal vtable based interface is not necessarily available or defined for a coclass (neither is dispinterface)
@ThunderFrame ... and the magic to convert a dispinterface into the vtable one (and vice versa), assuming the interface is available, is... ITypeInfo::GetRefTypeInfo(-2)
you should check if TYPEFLAG_FDUAL is set in the interface flags (from ITypeInfo:::GetTypeAttr... wTypeFlags) BEFORE doing the above call, or risk a crash
if it's a disp-only interface (i.e. not dual), then you're stuck and will need to simulate the getters/setters for those properties
> I don't know if it's a regression or not - I've never had it work. I'm using the latest release:
Rubberduck version: Version 2.1.1.2532 Operating System: Microsoft Windows NT 10.0.17046.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.8730.2127 Host Executable: MSACCESS.EXE
I have a main sub that makes use of a Client class: creates an array with 100 000 Clients and loops over the array 100 times, each time setting a different random number to each Client.
Sub start()
Application.ScreenUpdating = False
Dim j As Long
Dim clientsColl() As Client
ReD...
> This would allow for logging a test run (to a text file or some such) with the name of the test and a pass/fail flag instead of returning void. This would really help with integrating into an issue tracking system or allow devs to trace what's failing and perhaps watch for regressions.
> The test-explorer already supports copying the results of a test-run. It's not really useful to add these return values when Rubberduck can already export what you're looking for into XML, html, csv and Rich Text
> Rubberduck version: Version 2.1.1.2532 Operating System: Microsoft Windows NT 10.0.17046.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.8730.2127 Host Executable: MSACCESS.EXE
@Vogel612 See, they could have said that in the introduction. They just went directly into download links and then listing databases without really saying what it is. They get a F from me for the lack of clarity. I even thought it was something to do wiht Yahoo Cloud Business because of acronym.
Nope. Not totally. It could be read as a stock market benchmarking because Yahoo is also popular source for finances and that's what I first thought when I saw it.
> I know you closed this ticket and for good reason, but I would like to see if you'd be willing to reconsider giving us programmatic access to a return value on the Assert object. I am struggling to trace a failure and I think it's because I have interdependent tests so looking at a run log would be very helpful to track it down. It would also permit devs to run automated scripts against the log. Having to copy/paste the results is a manual task that should be automate-able.
> I hear you. In the .net world a failing Assert throws an exception, so you get a stack trace. We could make them throw a trappable run-time error (on top of the current behavior, i.e. handling the error wouldn't affect the test outcome).. but returning a value and executing conditional logic based on that seems like a wide-open door for abuse IMO. There must be a reason no testing framework implemented asserts that way...
> I'm removing the [feature-unit-testing] label, since this needs to be fixed at the GroupingGrid level: every single toolwindow that uses a grouping grid needs to support wheel scrolling, not just the test explorer.
@Duga @Mat'sMug just so I'm following - we make the rewriter implementation abstract then make all rewriters including the .... IDK, CodeStringRewriter derive from the new abstract RewriterBase class? Then the VBACodeStringParser would take a dependency on the CodeStringRewriter while the RubberduckParserState would take a dependency on CodeModuleRewriter ?
@this something like that yeah - but given CodeStringRewriter doesn't need a Rewrite override, I'd make it the base class, then the ModuleRewriter can derive from it.
> Closes #3642 Previously the TODO markers had a trailing space in the settings (not in the German localisation however) which served as the word boundary test for identifying TODO markers in comments. This change is to use regular expressions to match the TODO markers as whole words which is more flexible and less likely to get false positive from words ending with any of the TODO markers. Notes 1) French localised settings file also has trailing spaces but not updated as doing this created...
a great many XML changes (about space="preserve") so not sure if doing this right. If this is okay, I can modify the pull request. 2) Two copies of the file RubberduckUI.resx appear in the change log even though only one was changed. Seems to already have two copies in the repository (in RetailCoder.VBE/UI and Retailcoder.VBE/UI - note difference in capitalisation of letter C)
> Looks pretty good. Those two resx files have been causing us some problems; I didn't notice the difference in that C before--I may be able to get a handle on the fix now.
@this Good thanks. Finished my short contract and have now started a permie role. It's a bit of a learning curve, the tech is way newer than what I was stuck using previously. Not able to code at home for a couple of months, we've had a family member come to live with us, so I have no work area until I can build a garden office (hopefully a month or two).
@IvenBach Will do sir. AFAICT, the magic is a mix of codegen (files emitted to /obj on compile) and runtime XAML parsing. But I'm sure that's about 0.0001% of the full picture.
> The problem seems to be that the static event handler in `VBComponents` attaches only to the first `VBComponents` collection wrapped. However, the collections are per project. So, a static approach does not seem suitable.
To reproduce:
1. Open a workbook in Excel. 2. Open the VBE and parse. 3. Open another workbook. (This should trigger a parse.) 4. Add a module to the second workbook. (No parse)
I see now - it's from System.Runtime.InteropService
I can see why it's all weird AF. Yes, the events are supposed to be for the collections, AFAICS
TBH, my understanding of a delegate is a little shaky but if making a delegate static means that it's now shared for the type VBProjects, it would make sense why it wouldn't trigger on 2nd project.
as for the events on the VBProjects - TBH I don't even know if it's possible to have multiple instances of VBProjects -- I've never ever seen one. It does seem to me really weird that they'd implement on the collection, not the top-level VBE object.
That said, I think that even though they have this very weird setup, there is no reason we can make it more logical on the RD's wrapping code by implementing it on the VBE class - we would just += and -= everytime we got a reference to the wrapped IVBProjects.
> @retailcoder I investigated this matter a little bit and these are my thoughts:
The `.settings` file generates an XML file and a code-behind file. This code-behind file contains a `DefaultSettingValueAttribute` for every setting, where the value is a string holding the setting's XML. Even if RD is not able to read the `app.config` file (I don't see one in the `bin` folder), it will fall back to default settings, which are hard-coded in the code-behind file. While developing, any change to `
I have a main sub that makes use of a Client class: creates an array with 100 000 Clients and loops over the array 100 times, each time setting a different random number to each Client.
Sub start()
Application.ScreenUpdating = False
Dim j As Long
Dim clientsColl() As Client
ReD...
VBA Rubberducking
VBA Rubberducking