> Input and InputB were being created as Special Form SubroutineDeclarations, but they're functions, and they're declared in `_HiddenModule` as `_B_var_Input` and `_B_var_InputB`, so they can be created as Alias Form Declarations.
Likewise, `Array` is defined in `_HiddenModule`, so there's no need to Special-Form it.
I still can't get the `Width` procedure to resolve - I suspect there's a parser bug because Width's first argument is a file number that must be prefixed with a `#`.
> *Should* `Width` resolve to a function? VBA treats it as a function internally, but externally it's defined as a statement. The grammar for it appears to be correct: ``` // 5.4.5.7 Width Statement widthStmt : WIDTH whiteSpace markedFileNumber whiteSpace? COMMA whiteSpace? lineWidth; lineWidth : expression; ``` The VBE is similarly conflicted - it displays IntelliSense for it...
@Comintern the TSR works, but the fact that WS/line continuations and other junk are in the parse tree is a PITA
Assert.AreEqual failed. Expected:<>. Actual:<
Private bar As Long
>.
at RubberduckTests.Postprocessing.CodeModuleExtensionTests.RemovesSpecificVariableInDeclarationList() in c:\Users\Mathieu\Documents\GitHub\Rubberduck\RubberduckTests\Postprocessing\CodeModuleExtensionTests.cs:line 148
The latest The Ciber Crime Daily! http://paper.li/EdgarUlloa/1317433489?edition_id=51816880-0682-11e7-a350-0cc47a0d164b Thanks to @rubberduckvba @firox_ @JANIGAYL #anonymous #hack
It would be cool if they were "windowed" - i.e. forward and back buttons that showed each of the changes with a couple lines of code around it. That would be way too much work though.
Public Property Get Foo(bar As Long, baz As Long) As String
End Property
Public Property Let Foo(bar As Long, baz As Long, value As String)
End Property
Yep.
That makes me curious whether the refactor would currently break that code.
Regardless, I'd show whatever Get, Let, or Set members exist in the preview.
WTH does Enumerable.Repeat have a int for the count parameter?
> Line replacements the exceed the maximum line length are simply truncated by the VBE. This mangles code and leaves it uncompilable if the Indenter adds too much white-space to the beginning of a line. This is a bug that RD inherited from SmartIndenter - lines should only be indented up to a maximum width of 1024 characters.
Related, the VBE has a (ridiculous) maximum indentation level of 32. Since RD is falling back to the VBE setting if it isn't overridden by a user setting, RD should a
I'll probably post a reply later this afternoon. I have the legacy SmartIndenter installed, so I've been flagging unit tests with a // Broken in VB6 SmartIndenter. comment when I run across them. It's probably only the tip of the iceberg though.
> We intentionally left this out of the port from the legacy SmartIndenter because we frankly didn't see much of a use case for it (and it could potentially result in a cascade of opening code panes in a huge project). Now that the indenter is blazingly fast by comparison, this is mainly a constrained by what the user is willing to put up with.
Apparently users of the legacy version find this useful. See this [forum post](https://www.excelforum.com/excel-programming-vba-macros/1108949-smart
Hey - FYI, I am still reliably getting the same null DeclarationFinder exception. I'm current with what was merged yesterday. It seems to be isolated to Debug mode whether I start directly from VS or attach to the process. When I launch Excel on its own...all is well.
@Mat'sMug That - should have also addressed the selection event too. Are you still getting errors if you change the cursor position during the initial parse?
> Rubberduck perfectly worked for MSOffice hosts, when I tested it "for recruiting", but it broke down in ours 64-bit AutoCADs 2014 while VBE loading, so, it was easier to write self own simple tool for universally use while that time. But I will test it again for later :-)
> Yeah, I'm not sure exactly why they have it declared there and not the other file handling statements. I guess the main question. It does seem to be unique to Width though - none of the other file statements are declared anywhere. The Input* are all documented as both statements and procedures, but not Width. I wouldn't be surprised if that was added as a bug fix at some point, but who knows.
@Mat'sMug I listened to an interview with Joel Spolsky recently - he said SO was terrified for the first few years, that ExpertSexChange would just turn off their paywall. Then SO got critical mass, and EE did finally turn off the paywall, but about 8 years too late.
> Yeah, I'm not sure exactly why they have it declared there and not the other file handling statements. I guess the main question. It does seem to be unique to Width though - none of the other file statements are declared anywhere. The Input* are all documented as both statements and procedures, but not Width. I wouldn't be surprised if that was added as a bug fix at some point, but who knows.
> Oh, but the file-handling statements Input and Input B *are* declared in `_HiddenModule` - they're just the pesky Aliased variety. My current PR fixes their declarations - If only I could work out what is breaking the tests.
``` BSTR _stdcall _B_str_InputB( [in] long Number, [in] short FileNumber ); [helpcontext(0x000f735f)] VARIANT _stdcall _B_var_InputB( [in] long Number, [in] short FileNumber ); [helpcontext(0x000f735f)] BSTR _stdcall _B_str_Input( [in] long Number,
@Duga @ThunderFrame - Is it breaking the parser tests, or is it breaking in the resolver? I suspect this is similar to the Mid issue where the statement usage is colliding with the function usage.
Test Name: UntypedFunctionUsage_IgnoreQuickFixWorks
Test FullName: RubberduckTests.Inspections.UntypedFunctionUsageInspectionTests.UntypedFunctionUsage_IgnoreQuickFixWorks
Test Source: C:\Users\Andrew\Documents\GitHub\Rubberduck\RubberduckTests\Inspections\UntypedFunctionUsageInspectionTests.cs : line 153
Test Outcome: Failed
Test Duration: 0:00:00.0566929
Result StackTrace:
at System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
at RubberduckTests.Inspections.UntypedFunctionUsageInspectionTests.UntypedFunctionUsage_IgnoreQuickFixWorks() in C:\Users\Andrew\Documents\GitHub\Rubber…
@Comintern Width just doesn't get recognized at all. My PR does identify function usages of Input and InputB. Interestingly, the Input function takes arguments Number, #FileNumber, while Input statement takes #FileNumber, VarList (and VBE autocorrects an InputB statement to an Input statement)
> Actually there are several number of edge cases we test for, for which the single most effective "fix" involves a 50,000 V / 500 amp discharge in the keyboard.. or mouse... lol
Beep: Beep
duh
Much of the essence of building a program is, in fact, the debugging of the specification. - Fred Brooks (1986)
[rubberduck-vba/Rubberduck]build for commit 1b4e1810 on unknown branch: AppVeyor build succeeded (@ThunderFrame I don't build anything, I'm just the messenger!)
I used to work at a company that had a bot (called monkey) on a chat room. Type in =CONCAT("A","B","C") and monkey would have Excel resolve/evaluate the formula to a result. Type in !quoteadd username and it would add that user's most recent statement to a list of quotes. Type !quote and it would return a random quote.
a bot on this channel that had RD/RDWeb installed could offer: Type !Parse MsgBox prompt, vbInformation, title, helpfile, context and the bot could return the results to the chat...
^ Would it be information overload if the context text (with a selection inside countryCode), showed you the name/type of the countryCode variable and the name/type of Left's String parameter)? i.e. you'd have context about the variable AND where it is being used).
IKR - but a long custom function like FunctionDeclaration that has 13 parameters, it can be hard to know which argument you're working with, unless you delete and then reinsert a comma, in order to get the intellisense. (I have to do the same thing in VS, but maybe I'm missing something.)
Ctrl + Space for normal Intellisense, and Ctrl + Shift + Space for parameter Intellisense (e.g. to see what overloads are available in a method call which you've actually already filled in). I find the latter very handy :)
We have a few clashes with keyboard shortcuts in VBE... Ctrl+M should be "Import Module", but SmartIndenter co-opts it, Ctrl+Shift+I should be "Parameter Info", but RD co-opts it for "Show Inspections Window". Ctrl+R I can live with (although I'm not ready to fully surrender my Project Explorer just yet.
I know the original SI co-opted Ctrl+M, and that I can reconfigure hotkeys, but when there are so many free keys, it seems like we're burying some VBE functionality unnecessarily.
@Mat'sMug I know - Customization is easy (although I'm certain inertia stops many from bothering to adjust), but when co-opting built-in shortcuts users will undoubtedly choose different RD customizations if they want to restore the built-in shortcut, so, support/documentation becomes harder: "Did you press Ctrl+M, or whatever you have configured for Indent Module?"
@Mat'sMug Sure, but a user asks "I pressed Ctrl+M" and Excel went boom. Support requires asking what the user has configured for Indent Module and/or if the user has customized Ctrl-M for anything else, before any other meaningful support can be offered.
avoid clashes by default, let the user customize their own clashes.
look how ---angry-- delighted @FreeMan was with esc being "customized"....
What's the keyboard shortcut for VS2005/2008 to display intellisense box if accidentally hit ESC and want the box come back again? Thanks.
Ctrl + Space for normal Intellisense, and Ctrl + Shift + Space for parameter Intellisense (e.g. to see what overloads are available in a method call which you've actually already filled in). I find the latter very handy :)
VBA Rubberducking
VBA Rubberducking