RELOAD!

[Minesweeper] Games Played: 95, Bombs Used: 47, Moves Performed: 12981, New Users: 10

[rubberduck-vba/Rubberduck] bclothier created pull request #5586: Update InnoSetup version to merge bclothier/Rubberduck/installer into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] build for commit 40cbfa43 on unknown branch: AppVeyor build failed

BUILD FAILURE!

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #5586: Update InnoSetup version

[rubberduck-vba/Rubberduck] build for commit 4f0fa8ac on unknown branch: AppVeyor build failed

BUILD FAILURE!

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #5586: Update InnoSetup version

[rubberduck-vba/Rubberduck] build for commit 941ed192 on unknown branch: AppVeyor build failed

BUILD FAILURE!

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #5586: Update InnoSetup version

namespace memo.Controllers
{
    public class ControllerBase : Controller
    {
        public string getCurrencyStr(string symbol)
        {
            return "CurrencyResult"
        }
}

The my controllerS inherits? this class:

And use the function.

namespace memo.Controllers
{
    public class OffersController : ControllerBase
    {
        public ApplicationDbContext _db { get; }

        public OffersController(ApplicationDbContext db)
        {
            _db = db;
        }

        public IActionResult Index()
        {
            model.ExchangeRate = getCurrencyStr(curSymbol)
        }
    }
}

Or is there a better way to share "functions" like in a VBA where I just public declade them or in Python where I import the function from a file?

[rubberduck-vba/Rubberduck] build for commit c514431e on unknown branch: AppVeyor build succeeded

If you go the inheritance way, you should first ask yourself whether what you push to the base class will always change in the same way for all subclasses. If that is not the case, you might run into problems later on.

This applies even more for using static (extension)methods.

An alternative is to encapsulate common behaviour into its own class with an interface and to constructor inject that.

In order to do that for a controller that gets created on runtime, you will need a factory.

The capability to use such controller factories is built into many frameworks using controllers, like asp.net mvc.

@this Long time ago, not sure if you remember this (no pun intended). I was asking about how RD catches the stop button press/End statement when executing unit tests (to solve this bug and you pointed me towards some clever typeinfo related stuff. You then pointed out that because my Error handling code was living in VBA and so it would be like "cutting off the branch you are sitting on" trying to catch the issue...

... However I encountered another bug where the Stop Button wasn't killing all my timers when I called my API from an addin. This means that somehow the VBA in my addin survived the stop button. I'm wondering whether anyone has some understanding of this, and whether it's worth pursuing the typeinfo stuff

@Greedo I make @this pun any time I can! ;)

@Greedo to confirm something: when you press stop on the button, does the userform you use for timers actually unload? In my brief test, it did die but I don't use UF that much so there might be something else to make it survive the stop button.

Going off Access forms' behavior where Access forms will not unload when Stop button is pressed, while you still might have a valid hWnd, the internal state is lost which would then lead to undefined behavior when you continue to use the lobotomized form after pressing the Stop button.

[rubberduck-vba/Battleship] bradmwong forked us into bradmwong/Battleship

^GUI front-end inbound? :)

@this Yeah, this is as far as my observations have gone - the hwnd is definitely still valid, I don't think state is all lost because the way I can kill the timers is Set TickerAPI = Nothing (the api is a predeclared class). It holds a reference to a WindowsTimerManager which in turn holds a reference to an instance of the userform - I imagine each instance gets a unique hwnd? In any case looks like the reference chain must be kept alive or there would be no way to terminate the userform

um, I believe that even a predeclaredid class will be reset. You can prove this by setting up the Initialize event for the class and put a breakpoint.

Option Explicit

'@PredeclaredId
Private Sub Class_Initialize()
    Debug.Print "initialized"
End Sub

Public Sub foo()

End Sub

invoking foo several times will only print "initialized" on the first use. Clicking stop, then that prints again but only for the "first" time

Again, I'm not sufficiently familiar with userform's behavior but like Access forms, the hWnd never changes even if you click the stop. It's the internal VBA state that you need to be careful. If you can completely reconstruct the internal state or run stateless, then great, you're peachy.

Yeah I'll do some tests, I was just asking to see if anyone had some immediate thoughts. Yeah predeclared classes should be reset when global state is lost, but the ones in the addin (xlam) referenced from my main project (xlsm) seemed to be retaining some state/not resetting. Something weird is definitely going on

Interesting the hwnd stays the same though

well it's own project, isn't it?

that is, if you have the add-in project actively selected and a code pane open for one of its things, and you press stop, does that stop that project only?

I've seen subtle but different behaviors when working with projects that aren't the main project, so that might be a factor.

Or, that the stop button only has an effect on the main project, but not the subsequently loaded projects.

Yeah, if I run the addin code from within the addin stop kills everything as expected. It's only if I don't have it open but run it as a reference from the main project that things survive

Just thinking aloud here, don't want to waste your time, I can do some digging myself

@this Yeah this is what I'm talking about

Oh Workbook doesn't have an Initialize event

@Greedo right and stop doesn't effect the addin even if you have it referenced by a main project, but have one of modules from the addin open as the active codepane?

End statement does kill stuff, not the stop button, and the ObjPtr of TickerAPI persists across Stop but not End

Hitting stop kills stuff if run with a module active from the referenced project, but not otherwise (even a module open but just not active)

Cool so looks like Stop only kills state local to the project that's active (End is global)

So it may be possible to handle a stop button press from a vba addin

(sit on a different branch of the tree to the one you're cutting)

apparently so. Nice find!

[rubberduck-vba/Rubberduck] MDoerner created pull request #5587: Super types for document modules to merge MDoerner/Rubberduck/SuperTypesForDocumentModules into rubberduck-vba/Rubberduck/next

> Closes #5286 Closes #3569 This is a first PR to add knowledge about super types of document modules to RD. It works by getting the supertype names from the user com projects acquired via the type lib API and letting the type hierarchy pass do the rest. Unfortunately, the world is not so simple that this is sufficient. Apparently, different hosts employ different schemes for the supertypes and the VBE seems to employ some hack around type checks. - In the case of Excel, the interface...

implemented by the sheet modules is _Worksheet, but the VBE allows assignment to Worksheet variables, where Worksheet is the coclass. To emulate this, we add an additional supertype name without the underscore, unless that new name is the name of the original document. - Access actually introduces a dedicated hidden interface for each of the document modules, whose name is the name of the document prefixed by an underscore. This interface then inherits from the actual built-in one...

(_Report3, _Form3). Since we do not have declarations for the individual hidden interfaces, I have added a step that also adds the supertype names for the interfaces two levels up in case the naming convention for the direct interface is encountered. There are probably more variations in how documents are wired up, but that requires more investigation. Moreover, we could consider generating the declarations for the hidden interfaces from the user com project. However, that is probably...

something for another PR. In addition to adding the supertypes, this PR uses them to implement the new inspections ImplicitContainingWorksheetReferenceInspection and ImplicitContainingWorkbookReferenceInspection, which find unqualified references inside the appropriate document modules to members of Worksheet and Workbook that would reference ActiveSheet and ActiveWorkbook outside such document modules, respectively. The corresponding quick fix is the new QualifyWithMeQuickFix,...

which does the obvious thing. Naturally, the PR also removes the false-positives for ImplicitActiveSheetReferenceInspection and ImplicitActiveWorkbookInspection now reported by the two now inspections.

[rubberduck-vba/Rubberduck] build for commit 10d173f8 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] retailcoder created comment on pull request #5587: Super types for document modules

> Amazing work! Tried to do this a few months ago and got stumped at the "Unfortunately, the world is not so simple that this is sufficient" part - well done, and these new inspections are a great idea!

@Duga The request for the inspections was in the issue about the false positives.

Oh, one thing: I think this PR will conflict with the German translations update since git is so bad at diffing xml.

@M.Doerner would be practical to add a XML comment before the final root closing tag to our xml files? That may help avoid the conflicts

I noticed that conflict only happens when you add elements at the end of the file but not so much when it's in middle of the file which seems to get merged just fine.

I think the problem primarily pops up when you add something right next to something that gets changed. The the closing tags do not get handled correctly.

[rubberduck-vba/Rubberduck] bclothier added label PR-Status: WIP to pull request #5586: Update InnoSetup version

[rubberduck-vba/Rubberduck] bclothier edited pull request #5586: Update InnoSetup installer

@M.Doerner i'm curious - why we don't have declaration for the "hidden interfaces" for document modules? are we not picking it up via type library?

We currently only generate declarations from the user type library for locked projects.

Since there is one individual hidden interface for every document module in Access, I assume they are part of the user project as well.

Sounds to me we should be processing the unlocked projects as well. But that needs some thinking; you already commented against making declarations more nutable

@Feeds uh, no. masks for covid protect mostly the people around the wearer, not the wearer themselves. The key attribute is not the filter for inhalation, but expiration. Any mask that has an exhalation valve is worthless for covid use.

you'd be better off wrapping a scarf around your face than donning an FFP3 mask with a valve.

meh, too complicated. Just give giant hamster balls to everyone. #GoodEnough.

[rubberduck-vba/examples] jchen1624 forked us into jchen1624/examples

[rubberduck-vba/Rubberduck] mansellan created comment on pull request #5587: Super types for document modules

> Woah, that's impressive.

Does anyone know if string.Empty has the same characteristics as vbNullString (e.g. it's a null pointer, as opposed to a initialized zero-length string)?

[rubberduck-vba/Rubberduck] BZngr created comment on issue #4842: False Positive Inspection - Variable is used but not assigned - with ByRef assignment

> Example no longer generates an inspection result. Fixed by previous PR.

[rubberduck-vba/Rubberduck] BZngr closed issue #4842: False Positive Inspection - Variable is used but not assigned - with ByRef assignment

@this the existence of predicate string.IsNullOrEmpty would suggest it is an initialized empty string- no?

good point.