Impressive. I'd have never though to replace the screen. Especially since soldering is involved! (My soldering skills were never up to a task like that)
> **Rubberduck version information** Version 2.4.1.4627 OS: Microsoft Windows NT 10.0.15063.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4813.1000 Host Executable: MSACCESS.EXE
**Description** Members _within_ a module _are_ sorted according to the sort option setting, however, the modules themselves are _not_ sorted by this setting.
**To Reproduce** Steps to reproduce the behavior: 1. Using the `'@folder` annotation, put several modules in an RD folder 2. C
> Note that this doesn't enforce the same constraints as the VBE when parsing the lineSpecialForm. Most notably, the form `foo.Line -(x, y),` does not provoke a parser error, even though it does not compile.
The grammar should correctly deal with all cases that do compile.
too many people use TypeName() or VarType(), and never get to know about the TypeOf operator.
Even though TypeOf is better --- it can tell you whether you are dealing with a ADODB.Recordset or DAO.Recordset; TypeName() only gives you a Recordset which is unhelpful.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4884?src=pr&el=h1) Report > Merging [#4884](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4884?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **not change** coverage. > The diff coverage is `n/a`.
it also helps to realize that TypeName() and VarType() are built to work with variants specifically and was never meant to be used as a general purpose reflection function.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4884?src=pr&el=h1) Report > Merging [#4884](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4884?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **not change** coverage. > The diff coverage is `n/a`.
BuiltInTemplate_ExistingFile_NotCreated:
Message: Moq.MockException :
Expected invocation on the mock once, but was 0 times: h => h.Exists
No setups configured.
No invocations performed.
---
BuiltInTemplate_File_Autocreated:
Message: Moq.MockException :
Expected invocation on the mock once, but was 0 times: h => h.Exists
No setups configured.
No invocations performed.
---
BuiltInTemplate_ReturnsCorrectCaption:
Message: Expected string length 40 but was 20. Strings differ at index 0.
Expected: "Klasse mit PredeclaredId-Attribut (.cls)"
Holding a flower with a smile plastered on her face?
Sounds like she might be twitterpated
North American informal
1. Infatuated or obsessed:
Gus is still hopelessly twitterpated by Lee
smiling into each other’s eyes, a seemingly twitterpated couple glided
1.1 In a sta...
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4885?src=pr&el=h1) Report > Merging [#4885](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4885?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4885?src=pr&el=h1) Report > Merging [#4885](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4885?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `100%`.
> **Rubberduck version information** The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:
Version 2.4.1.4627 OS: Microsoft Windows NT 10.0.17134.0, x64 Host Product: Microsoft Office x64 Host Version: 16.0.11328.20222 Host Executable: EXCEL.EXE
**Description** On Error Goto -1 is a legitimate statement to clear a previous On Error statement See https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/statements/on-erro
> Thanks for reporting! I'm not sure if you saw the entire message (or perhaps a separate inspection):
``` While this is legal, this is poorly documented "feature" that means something different -- the error state is also cleared in addition to disabling any error handling. However, this can be ambiguous as a negative line label of -1 may end up as a target and excessively complex error handling usually indicates a need of refactoring the procedure. ```
> Thanks for reporting! I'm not sure if you saw the entire message (or perhaps a separate inspection):
> While this is legal, this is poorly documented "feature" that means something different -- the error state is also cleared in addition to disabling any error handling. However, this can be ambiguous as a negative line label of -1 may end up as a target and excessively complex error handling usually indicates a need of refactoring the procedure.
> The title of the page you linked to is **On Error Statement _(Visual Basic)_**.
Note also references to: `Whenever possible, we suggest you use structured exception handling in your code, rather than using unstructured exception handling and the On Error statement. For more information, see Try...Catch...Finally Statement.` Also references to: `Throw Statement`
That's _not_ VBA, which is what you're using in Excel.
> I am a bit confused here. Where exactly is it relevant that the commands are transient? As far as I know, they are all injected or constructed inside the constructor of a view model. I do not think that we use factories for them.
Public Sub x()
On Error GoTo Oops
Debug.Print 1 / 0
Exit Sub
Oops:
On Error Resume Next
Debug.Print 1 / 0
End Sub
Public Sub y()
On Error GoTo Oops
Debug.Print 1 / 0
Exit Sub
Oops:
On Error GoTo -1
Debug.Print 1 / 0 'INFINITE LOOP!
End Sub
but with the second case, it basically resets everything.
Yes.
come to think of it, the VB.NET documentation doesn't really suggest that.
> GoTo 0 Disables enabled error handler in the current procedure and resets it to Nothing. GoTo -1 Disables enabled exception in the current procedure and resets it to Nothing.
> My point is that being registered as transient does not mean that the object gets created later than other objects or even once after the initial resolution of the object graph. All it means is that a separate object gets injected at each injection point.
So, if there is no automagic factory providing commands, all injected commands are there after the initial resolution.
I mean, if your error handler is so complex to warrant a legit use of On Error GoTo -1, you most likely need to refactor it, not use it....
@Duga but how does that prevents us from not having a command that is created after the event?
I don't see that guarantee, even if all objects were simply caching their commands. That means I have to walk up all consumers' tree to ensure that commands are not injected in a transient object.
> Here's the documentation for the `On Error` statement *in VBA*: https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/on-error-statement
Note that `GoTo -1` isn't one of the documented options, and experimentation leads me to believe that in VBA `On Error GoTo -1` is indeed legal, but behaves exactly like `On Error Resume Next` outside of an error-handling subroutine, **and has nefarious, undocumented side-effects inside an error-handling subroutine**:
I get the point that you want to guard against creating commands too late. My sole point is that this really has nothing to do with the lifestyle they are registered with.
If you have a singleton you provide via an automigic factory and only resolve it later, it will only be created at thefirst request, AFAIU.
Yes, I appreciate that - I'm a bit surprised that IoC apparently news up everything during the registration; I would have expected that for a transient object, it'd be only new'd up when it was needed.
Correct. When I saw that the commands were provided with a transient lifestyle, I was concerned that I might not be able to guarantee that all commands will be present when we fire the event.
and I did not want to change the lifestyle or walk up all the object graph to work out the actual lifetime.
> Thanks for the quick reply, and the suggestion – much appreciated!
________________________________ From: bclothier <notifications@github.com> Sent: Tuesday, April 2, 2019 9:33:43 AM To: rubberduck-vba/Rubberduck Cc: MegaDudeNZ; Author Subject: Re: [rubberduck-vba/Rubberduck] On Error Goto -1 causes a "That's not real code" (Thundercode) error (#4886)
Thanks for reporting! I'm not sure if you saw the entire message (or perhaps a separate inspection):
Thanks for the quick reply, and the suggestion – I’ll rewrite it accordingly. Much appreciated!
Nev
________________________________ From: Mathieu Guindon <notifications@github.com> Sent: Tuesday, April 2, 2019 10:02:02 AM To: rubberduck-vba/Rubberduck Cc: MegaDudeNZ; Author Subject: Re: [rubberduck-vba/Rubberduck] On Error Goto -1 causes a "That's not real code" (Thundercode) error (#4886)
Here's the documentation for the On Error statement in VBA: https://
because you can't change the policy while the error handler is active
You need to first inactivate the error handler by doing a Resume, Resume Next, Resume <label> or maybe even Exit <procedure>..... or doing a On Error GoTo -1
Public Sub x()
Dim db As DAO.Database
On Error GoTo ErrHandler
Set db = ...
db.BeginTrans
On Error GoTo TranErrHandler
'do work
db.CommitTrans
On Error GoTo ErrHandler
'do post-work
ExitProc:
'Clean up....
Exit Sub
TranErrHandler:
db.RollbackTrans 'Fall through
ErrHandler:
'default error handling stuff
End Sub
Holding a flower with a smile plastered on her face?
Sounds like she might be twitterpated
North American informal
1. Infatuated or obsessed:
Gus is still hopelessly twitterpated by Lee
smiling into each other’s eyes, a seemingly twitterpated couple glided
1.1 In a sta...
VBA Rubberducking
VBA Rubberducking