@this Look at this beautiful thing you helped me do:
Private Function InitialErrorsFound() As Boolean
Select Case True
Case _
AllReportsInSetAreNotTheSameType, _
MaximumSourceReportsAtOneTimeExceeded, _
OtherExcelFilesAreOpen, _
SourceReportsPresentFromMultipleWeeks
InitialErrorsFound = True
Case Else
InitialErrorsFound = False
End Select
End Function
Ah @Vogel612 when you have a moment for me, please assist me in how you found out a product was excluded and how this link to security mattered. I looked at the provided link and gone around in circles not understanding the context that this feature is removed among these risks...
@puzzlepiece87 Yeah, it's very easy to add more conditions in that way. FWIW, Case Else is kind of redundant because the default value for the boolean is false.
> As I deal with broken projects and sprawling hand-me-down codebase, I'm very annoyed that I can't even use code explorer *unless* the whole project can parse, forcing me to have both CE and PE open, which feels a bit silly and awkward.
Code explorer ought to support graceful upgradation* - instead of requiring a parsing to use it, it should start with only basic information that is already exposed in the PE which is easily had by enumerating the `VBProjects` + `VBComponents`. That would at
> Just to add - I agree that the initial sample smells but this shouldn't smell:
``` #If LateBind Then Dim FSO As Object #Else Dim FSO As Scripting.FileSystemObject #End If
Set FSO = CreateObject("Scripting.FileSystem") ```
Keep in mind that in current implementation, the above code is perceived by RD exactly same as the original sample, assuming the `LateBind` is set to false. The inspection should not raise in this case, though it might be hard given that we are given only one "
> We'd need some kind of "pre-parser" service that could spit out a bunch of temporary Declaration instances that the ViewModel could consume... and this means inserting an abstraction between the ViewModel and the parser state declarations, because we wouldn't want these "temp declarations" to interfere with parser state. IOW it's more complicated than it appears to be.
> @bclothier nobody is forcing anyone to act on inspection results, or to apply available refactorings... IMO this has all looks of a "thanks ducky, I know what I'm doing" case, where you'd just ignore the given hint.
@Duga IDK about others but when I see thousands of results, it make me sad and also more likely to ignore the inspection altogether. OTOH, I'm probably setting the bar too high in asking for accurate analysis that accounts for 100s of edge cases. ;)
@PeterMTaylor IDK. I'm not exactly an Excel guy. Curious that they didn't have Switch() until recently - Access has had Switch() and also Choose() for a while. That said, if you have complex conditionals, you probably want to use VBA instead of formulas and reference that from your formula, no?
@Vogel612 Actually, AIUI, they removed the legacy version of Equation Editor from Office. There's been a new Equation Editor in Office since Office 2010. The compromised Equation Editor was only kept around to allow people to edit files created with it. Granted, there are still old files that might require editing, but IDK what MS is offering in terms of support for that...
Hey - I merged with the latest. I'm unable to compile successfully. The message is: Severity Code Description Project File Line Suppression State Error CS1617 Invalid option '7.2' for /langversion; must be ISO-1, ISO-2, Default, Latest or a valid version in range 1 to 7.1. Rubberduck.SettingsProvider C:\Users\Brian\Documents\GitHub\VisualStudioProjects\Rubberduck\Rubberduck.SettingsProvider\CSC 1 Active
TBH my fully idiot-proof order form displays a huge "MACROS ARE CURRENTLY DISABLED, FUNCTIONALITY IS LIMITED" banner if it's opened with macros disabled
Was just curious if my experience is biased because when I deal with Excel as reports, they do not like it very much if files contains those kind of alerts; so we distribute .xlsx files as a rule to avoid those kind of stuff.
Sometime ago, we had an argument over how widespread basic Excel skills were. I was arguing that far more people know how to do SUM and VLOOKUP than they do a VBA function by an order of magnitude or two.
@Mat'sMug, sure. I think very relatively few people even get as far as VBA. What I thought was that anyone who has used Excel daily would know something about VLOOKUp
So you'd say that VLOOKUP and Pivot Table are known by people on tenth order of magnitude above basic VBA? Because earlier you were describing users who use it for decade and are still baffled at VLOOKUP.
No worries - As I said, I was just curious to see if my perceptions were skewed when I expected roughly 10x people to know basic Excel over those knowing VBA.
Because it's weird when I am given a bunch of excel spreadsheets to clean up and when I give them a xlsm they go all "woah woah, we ain't touching that!"
(that was years ago, though. Ever since then, I've always given them xlsx)
basically it's like if in the process of doing your job you needed to use, say, a screwdriver. So you're given a drill with a set of 35 tips, and all you ever do with it is stick the pointy end onto a screw head, and then run in circles around it
until a "power user" sees you and says "you know, it would be much easier if you pressed that button here"
When I run all the unit tests, I now get a one failing test...EmptyIfBlockInspectionTests - the InspectionType test. Trivial to fix...but I'm wondering if the test failure showed up earlier?
So you've written a beautiful piece of code, a macro that does everything it needs to do... the only thing is that, well, it takes a while to complete. Oh, it's as efficient as it gets, you've put it up for peer review on Code Review Stack Exchange, and the reviewers helped you optimize it. You need a way to report progress to your users. There are several possible solutions...… Continue …
Maybe into ProgressIndicator a Let like Public Property Let IsCancelRequested(ByVal vNewValue As Boolean) this.cancelling = vNewValue End Property And into DoWork If progress.IsCancelRequested Then Dim vbMsgBoxRes As VbMsgBoxResult vbMsgBoxRes = MsgBox("Cancel this operation?", vbYesNo) Select Case vbMsgBoxRes Case vbYes: Exit Sub Case vbNo: progress.IsCancelRequested = False End Select End If ?
@this I was working yesterday night on a Bosch BME280 chip, setting registers and reading libraries to try to extract useful code and I can truly support that statement.
@Hosch250 I made it fairly clear in the email that I didnt want my boss to know just yet. I dont mind telling him in general, but again I just dont want to rock the boat for no reason. If the compensation is at a level where I would apply, I would tell him before applying. Its not a situation (thankfully) where I feel like there would be any issues if it was a position I intended to pursue and accept.
I mean, there would be some concern on the team, and we would need to take care of those, but he wouldnt be angry or anything.
> @kwnwzlnd the indenter hotkeys match the original Smart Indenter add-in's hotkey mappings, that's by design. .2718 should have the CE default mapping back to Ctrl+R though... :confused:
hi all. @Mat'sMug, @M.Doerner, @this... it occurred to me that really the only reason for wanting to use a shim now is to protect against other managed addins incorrectly disposing of shared RCWs that RD may also be holding on to...
And it appears that there is a neat way around this, without a shim.
@NelsonVides note I'm not exposing a mutator for the IsCancellationRequested property (it wouldn't make sense for the worker code to be able to do progress.IsCancellationRequested = True)
Exceptions in the managed world shouldn't spill over, but instead will be propagated as COM exceptions to the host. The host shouldn't blow up unless it's an AV or similar, in which case it probably didn't come from any managed code
Naturally, I'm talking about once the COM stuff is all being released appropriately
I don't believe the shim will do much for you, once your COM interop is tight, and if you were to use unique RCWs. But that said, it wouldn't hurt either.
The shims have got the potential to hide a lot of issues. Issues that can, and mostly already have been, solved more appropriately. If you're going to go the shim route I'd suggest not using it for debug, only for release.
Years ago, I was tasked with maintaining a Word add-in. It originally used shim, too. I moved it to VSTO because 1) I was young and foolish and probably didn't understand what it was doing and 2) because VSTO made debugging and diagnosing much easier.
(just remembered - another reason I ended up moving away from shim was because it was written for 32-bit only and they needed it to run on 64-bit Word, too. I think that's what drove the decision to use VSTO - I had no C++ expertise to know what the hell to do)
as an example suppose I have to insert into a table from a staging table -- my process goes like so: 1. Script As -> INSERT INTO -> To clipboard 2. Delete the auto-generated VALUES part 3. Script As -> SELECT -> To clipboard 4. Paste to the place where the VALUES was 5. Tweak as needed
Yes, it's a necessity with loosey-goosey language like VBA who loves to surprise us with its delightful black voodoo implicit conversions.
VBA Rubberducking
VBA Rubberducking