VBA Rubberducking

12:01 AM

RELOAD!

[rubberduck-vba/Rubberduck] 3 opened issues. 1 closed issue. 6 issue comments.

[Zomis/Games] 2 commits. 1 issue comment. 63 additions. 21 deletions.

[Minesweeper] Games Played: 140, Bombs Used: 80, Moves Performed: 19607, New Users: 15

2 hours later…

mansellan

1:37 AM

heh, Unviewable+:

> Protection Type Descriptions

HIDDEN MODULES
Standard modules will be hidden (classes and userforms will still be visible). The VBA project won't be locked, so any module type can be added and saved. Procedures can be called from hidden modules, but VBA code cannot be read from them using the VBA extensibility library.

UNVIEWABLE PASSWORD PROTECTED VBA PROJECT
Unviewable password protected VBA projects are less secure than the equivalent locked projects, as recovery information has to be maintained within the file.

I know the ingredients of your lunch...

Hidden Modules: Rename the storage stream to include a leading _

Password protected: standard VBA password, possibly combined with #1

Unviewable locked: Remove compressed source and editor-format streams, leave just the pcode.

Or perhaps (according to the link in the first comment) it's just messing up the VBHeader. That would be, uhm, less than fully secure.

8 hours later…

9:18 AM

[rubberduck-vba/RubberduckWeb] APATRI0T created comment on issue #79: 404 Pictures

> Ok)

3 hours later…

FreeMan

12:24 PM

@MathieuGuindon makes note to put money where mouth is

3 hours later…

HackSlash

3:38 PM

@mansellan This might interest you: ratexcel.wordpress.com/2017/03/22/…

Then there is this: docs.microsoft.com/en-us/openspecs/office_file_formats/ms-ovba/…

1 hour later…

mansellan

4:58 PM

It does indeed, thanks :)

3 hours later…

8:02 PM

[rubberduck-vba/Rubberduck] Senipah opened issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> **Rubberduck version information**

```
Version 2.5.0.5457
OS: Microsoft Windows NT 10.0.18363.0, x64
Host Product: Microsoft Office x64
Host Version: 16.0.12730.20270
Host Executable: EXCEL.EXE
```

**Description**
As shown in the below screen shots, running unit tests which took 2:42 in 5443 takes 1:05:03 in 5457.

**To Reproduce**
Steps to reproduce the behavior:
1. To run exactly the same unit tests as me you can download the modules from here: https://github.com/Senipah/VBA

[rubberduck-vba/Rubberduck] Senipah added label bug to issue #5513: Unusably slow running tests in v2.5.0.5457-pre

[rubberduck-vba/Rubberduck] Senipah created comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> This would seem to be a UI issue as the individual tests have about the same duration as with previous versions. There are 4 long running tests that take around 600ms (because I couldn't be bothered to mock) and the rest are all ~15ms).
![durations](https://user-images.githubusercontent.com/4821959/83805421-c7cbe880-a6a7-11ea-8baa-10e1deb93a1e.png)

[rubberduck-vba/Rubberduck] Senipah edited comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> This would seem to be a UI issue as the individual tests have about the same duration as with previous versions. There are 4 long running tests that take around 600ms (because I couldn't be bothered to mock) and the rest are all ~20ms).
![durations](https://user-images.githubusercontent.com/4821959/83805421-c7cbe880-a6a7-11ea-8baa-10e1deb93a1e.png)

[rubberduck-vba/Rubberduck] Senipah edited comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> This would seem to be a UI issue as the individual tests have about the same duration as with previous versions. There are about a dozen long running tests that take around 600ms (because I couldn't be bothered to mock) and the rest are all ~20ms).
![durations](https://user-images.githubusercontent.com/4821959/83805421-c7cbe880-a6a7-11ea-8baa-10e1deb93a1e.png)

[rubberduck-vba/Rubberduck] MDoerner created comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> Do you also experience the long run times when grouping by something else than the test outcome?

I ask because there is a known slowness issue when grouping that way.

8:50 PM

[rubberduck-vba/Rubberduck] SteveLaycock created comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> I have noticed that if you group the tests then the form does not reorganise itself whilst the tests are running. If you do not group the tests then each test that passes is moved to the top of the list and the whole form is redrawn. This slows down the testing quite a lot.

[rubberduck-vba/Rubberduck] Senipah created comment on issue #5513: Unusably slow running tests in v2.5.0.5457-pre

> Hi @MDoerner

Looks like that's the issue.

By location took around 20mins:
![5457-location](https://user-images.githubusercontent.com/4821959/83808620-044e1300-a6ad-11ea-8bcb-e2eeff82d582.png)

But by category took only 32 seconds!
![5457-category](https://user-images.githubusercontent.com/4821959/83808812-54c57080-a6ad-11ea-818e-57f7fc74add0.png)

I'll use category from now on I think 😄

Assume this issue is a dupe so feel free to close.

9:08 PM

just curious - anybody ever used xstx template files? Why or why not?

9:25 PM

VBA UserForm has Controls that can be looped For Each/Next, but the type is Controls not Collection. Seems odd. Any insight?

9:40 PM

To use For Each, there only has to be amember with UserMemId = -4 that provides an iterator.

@M.Doerner thanks for that, but it seems counter-intuitive (to my limited way of thinking) that its Type isn't Collection since it acts like a collection. Is there something special that needs doing (or not doing) that precludes it being a Collection?

Or just "the way it was implemented"?

A Collection is a specific type that contains Variant containers.

It is just one thing that implements an enumerator member.

So to limit it to holding Control objects its specifically implemented that way... Thank you

You have the same for Worksheets and Fields.

Since I had never tried to assign either of those to something I wanted to use I never encountered it before.

Learned something today. Time for Cocktails!... Thanks again.

@M.Doerner "IEnumerator" or somthing like that?

9:50 PM

Just to clarify -- the For Each requires that the collection object implements the IEnumVARIANT interface

so it actually implements over Variants, not a specific object type.

Some of them are guaranteed to provide a specific type, though.

For that reason, it's legal to do Dim ctl As MSForms.Controls : For Each ctl In ... and Dim obj As Object : For Each obj In.... and even Dim foo As IFoo : For Each foo In ...

Note that in the last case, you may get a runtime error

the compiler will not check that the iterator type is valid; only that it can be an object or a Variant.

@this you wrote: "For that reason, it's legal to do Dim ctl As MSForms.Controls" did you mean "For that reason, it's legal to do Dim ctl As MSForms.Control" (singular)?

Sorry. Yes.

WHew... <G>

9:55 PM

But my point stands, though - the compiler won't tell you that Dim ctl As MSForms.Controls is wrong data type for the For Each

unless the Controls collection actually contains exclusively Controls objects

Gotcha! But it will throw a Run Time Error as Type Mismatch?

And to think I used to think I knew my way around VBA... LOL