« first day (1322 days earlier)   

12:01 AM
RELOAD!
[retailcoder/Rubberduck] 13 commits. 3617 additions. 1699 deletions.
[rubberduck-vba/Rubberduck] 18 commits. 1 opened issue. 5 issue comments. 3757 additions. 1723 deletions.
 
 
2 hours later…
2:30 AM
@ThunderFrame I am thinking you might be right about the word object model. Today, I found out that macro recorder lies completely about what is being done on the UI. I knew macro recorder was crapatastic with its reliance on ActiveAnything and Selection and implicit references but I never thought it'd come up with random code that doesn't even correspond to what I did via UI.
 
0
A: Group lines of code in vba

Tony DThe short answer is no, not out of the box. You can install 3rd party tools to do this, like this open source tool http://rubberduckvba.com/ If you have a lengthy procedure you may what to ask yourself if it does more than one thing. Generally a procedure should only do one thing as a rule. Then...

Apparently RD has code folding!
@this I think it's because lots of stuff still uses WordBasic function calls behind the scenes, and the Macro Recorder doesn't "see" those steps.
 
@ThunderFrame now that others are recommending RD for stuff it doesn’t yet have there might be some fly bys
Your princess is in another castle, for the time being.
 
@IvenBach Your princess is frolicking in another IDE.
 
@ThunderFrame Hmm. Interesting. FWIW, that was the first time I saw recorder lie so blatantly to me. Is that even the case with basic stuff? In my case, I was simply doing a ApplyListTemplate -- recorder says I should take one from the gallery but in actuality all I needed was ApplyDefaultNumbering . Netiher feel like a leftover from WordBasic.
 
3:06 AM
@this IIRC, a lot of the dialogue are launched by WordBasic. Office 2007 macro recording was a lie....
 
> This PR refactors the functions within ParserRuleContextHelper.cs (PRCHelpr) to ParserRuleContextExtensions.cs (PRCExtensions). The PR is a follow-on to the suggestion made in comment(s) for #3684 where I had made use of PRCHelper. In addition to porting the functions, I am proposing some modifications and renaming. 1. In the existing PRCExtensions, there were several overloaded versions of GetProcedureSelection(...). These overloaded functions may have been solving a problem that no...
longer exists. None of the functions are referenced by the code base (except one that is referenced by a test). I have removed these un-used functions as part of this PR. I am also proposing some new method names. The terms "Parent" and "Child" are used in a few methods names where "Ancestor" and "Descendent" would be more precise/descriptive given the method's current behavior. 1. The overloaded methods HasParent are changed to IsDescendentOf(...). 2. Method FindChildren did not stop...
at the context's "children" list but rather walked the entire parse tree. I have changed this method name to GetDescendents(...). 3. Method GetParent - which would imply (to me) a function that simply returns context.Parent, returned the the context itself (if it is the correct Type), or the first ancestor of the correct Type. I've modified this function to only return the first qualifying Ancestor (IOW, a context cannot be it's own Ancestor/Parent). I have changed the name of this...
method to GetAncestor. The DeclarationFinder referenced HasParent and GetParent. It has been updated to use equivalent logic: e.g., context is T || context.IsDescendentOf<T>()
[rubberduck-vba/Rubberduck] build for commit 189f1c95 on unknown branch: AppVeyor build succeeded
 

« first day (1322 days earlier)