pretty sure the execution time only counts the amount of time spent during the test method invocation. not the COM interop overhead, not the @TestInitialize/@TestCleanup, not the @ModuleInitialize/@ModuleCleanup`
Also, for you, I'd actually recommend a web app service, not a VM.
I'm only doing a VM because I can buy a Windows 10 Pro VM and run a couple dozen microservices and SQL servers for cheaper than running a single app on a web app service.
Hey everyone! I just applied the hotfix "Add attribute annotation" and it did add the annotation, but then it also replaced every EM dash (—) in the module with this: — Is this something you've seen before?
Right, I have run into the problem exporting and reimporting modules, but never with RD. I've also never used this particular hotfix (I don't actually know what it does).
lol yeah... VBE likes ANSI (but then somehow handles Japanese), and then .NET likes UTF-8.. the two together tend to get tricky
@ChrisB the "Add annotation" quickfix adds an '@Annotation comment that mirrors a given attribute; the "Add attribute" quickfix adds an Attribute VB_Something hidden attribute in the exported module that mirrors the corresponding annotation, then re-imports the module
e.g. '@PredeclaredId ensures Attribute VB_PredeclaredId is True; '@ModuleDescription controls the value of Attribute VB_Description at module level, etc.
@Duga not sure about the critical label there... I mean, sure it's annoying, but the work-around is to build with a Visual Studio version that's not completely broken.
"can it build web stuff? yeah? ship it!"
"oh, breaks every Windows project ever made... ship it anyway!"
> On what seems to be a related note, EM dashes — are converted to — in both string literals and comments when the hotfix is applied. My workaround is easy...don't use EM dashes, but I see how that would be a problem if all my comments were written in French.
> Or Japanese, or Russian, or ....anything outside of ANSI, really: this problem is wrecking any non-ANSI content in any code module - added "critical" label, this can be a very disruptive (potentially showstopper) problem for the affected users.
@IvenBach His name was familiar from my earlier digging through .NET docs or something something, and when he posted here, I got curious, moused over his name and there it was.
<thinkingbig>Would be cool to have a quickfix that will "Add DirectCast and do it automatically for the return value of WorkSheets.Item()"</thinkingbig>
> I don't think that the problem is related to the language used, whatever it is, but rather to the fact that VBE works only with ANSI encoding and not with UTF-8. When I export the module in which the attribute was added by RD, the file should be encoded in ANSI but this is not the case, it is UTF-8. If I convert this file to ANSI, the problem disappears.
@this I can't think you enough about your continued belts-n-suspenders full declaration of types. That has made once mystical examples mundane an consumable.
> My only issue with enforcing early binding is the problem it causes users with different versions and therefore requiring different references… I’d rather develop in early bound mode and then go late-bound when deploying. Maybe that is what you are suggesting and I am missing the point (which is usually the case… <G>).
From: Mathieu Guindon <notifications@github.com> Sent: Thursday, April 25, 2019 10:09 PM To: rubberduck-vba/Rubberduck <Rubberduck@noreply.github.com> Cc: Subscribed <subsc
> My only issue with enforcing early binding is the problem it causes users with different versions and therefore requiring different references… I’d rather develop in early bound mode and then go late-bound when deploying. Maybe that is what you are suggesting and I am missing the point (which is usually the case… <G>).
> @SmileyFtW the version-specific issues of early binding are real, but also wildly overstated. Scripting runtime, for one, has no reason to be late-bound: every single Windows machine built this century is running the same version. Ditto with any XML library, or regex, and several others. That said we can't hook the compiler (that I know of) and *enforce* it at compile-time; best we can do is trigger inspections, and offer quickfixes where appropriate. The vast majority of VBA code uses only s
@Duga I have to remind that on a computer where they disable the scripting, the application that uses early binding is totally SOL. At least with the late binding, there's the option of continuing to use the application without the features that directly depend on the scripting.
thinking about it - VBA's loosey-goosey really does not help clarify the difference. As you said, we can easily go late bound in a chained call or something like that. Don't even need a CreateObject or Object for that.
Sub Dateandpricegenerator()
'Projected Dates 1
mystart = Range("C7")
myend = Range("C8")
Range("B31") = Application.WorksheetFunction.EDate(mystart, 0) + 1
mystart = Range("B30")
For x = 31 To 100
If mystart >= myend Then Exit For
Cells(x, 2) = Application.WorksheetFunction.EDate(mystar...
VBA Rubberducking
VBA Rubberducking