> In software engineering, we use mocking frameworks to stand in for missing or complex parts of a system in unit testing. You know, it's like making a mockup of something. They don't actually mock us. Taunting frameworks, on the other hand...those can be quite rude.
Also, I need to take this to heart:
> Also, this is a pretty good narrative on how business people can spin any skill you have into whatever buzzword a customer thinks they want.
> A man in NY was stabbed in 1957. He recovered from his stab wound and lived until 2014, into his 90’s. When he died, the autopsy determined that the stab wound from 57 years earlier was a contributing cause of his death and it was declared a homicide.
VBA has a built-in functions for repeating a single character:
Function String$(Number As Long, Character) As String
Function Space$(Number As Long) As String
But neither are of any use when you need to repeat a string that has more than one character.
You could repeat a string "abcde...
Your code will fail with Overflow error when ActiveSheet.UsedRange.Rows.Count > 32767. Declare your variables as Long, and use meaningful names l is too visually similar to 1 and doesn't have any meaning to your future self or replacement. — ThunderFrame24 secs ago
@Mat'sMug I won't be able to do this by our next release, but what do you think about me completely revising the inspections feature all in one blow?
I should be able to get some work done on it in April, but after that (around May), I'm going to fulfill my promises to the Roslyn and F# tooling teams.
@Hosch250 I mean from a user behaviour point of view. A way of measuring their bad coding habits. Was thinking to myself when I hear a pattern that moderators of this club is slowly more frustrated than the normal about copy/paste code by other users questioning it
This wondering what's this like across other tags so to speak with stack overflow
^ Thus not this I meant silly iPhone auto corrector
I would like that this code would now be done in a faster way:
Sub TechMapping()
Set mappingWB = Workbooks.Open(Filename:="path\workbook1.xlsx")
Sheets("Sheet1").Activate
Dim Lookup_Range As Range
Set Lookup_Range = Range("A2:P1779")
Workbooks("workbook2.xlsb").Activate
...
Questions like this from veteran members demonstrate that the rules and principles we attempt to hold to are by no means straightforward or simple. They're [sort of] self-contradictory and mystical ... as any good set of rules should be. And, I'd like to believe questions like this humble the wise, and give hope to those feeling hopelessly stupid. Thanks, Robert! — svidgen16 hours ago
@Mat'sMug I've seen that it's not all hard cut lines and 90 degree angles. It's nice seeing others with more experience than myself ask questions that I would ask.
Basically, being a software developer requires knowledge of the basic principles, knowledge of the language(s), experience, and a goodly amount of uncommonsense and good humor.
@Duga @Mat'sMug suggested that I take a look at refactoring RenameRefactor - which is how I found this. I also have a fix....but still working on the refactoring.
Are optional parameters best eliminated if possible? IE if multiples calls can be made to a method and only 1 will use an optional parameter is it better to make everything explicitly pass in the parameter and not have it optional?
> @BZngr I guess it is a typo in your first method that you omitted the `I` in `Dim c1 As IClass1`, right?
Given that, I can fully reproduce this when renaming any public sub on an interface. As remarked above, it does not matter whether the method is called via an interface. Whenever the interface of a class gets implemented, no references are updated by `RefactorRename`, period. Only the implementing methods get adjusted.
Since we currently do not clean up sub and super classes when we r
> @BZngr I guess it is a typo in your first method that you omitted the `I` in `Dim c1 As IClass1`, right?
Given that, I can fully reproduce this when renaming any public sub on an interface. As remarked above, it does not matter whether the method is called via an interface. Whenever the interface of a class gets implemented, no references are updated by `RefactorRename`, period. Only the implementing methods get adjusted.
Since we currently do not clean up sub and super classes when we r
> @BZngr I guess it is a typo in your first method that you omitted the `I` in `Dim c1 As IClass1`, right?
Given that, I can fully reproduce this when renaming any public sub on an interface. As remarked above, it does not matter whether the method is called via an interface. Whenever the interface of a class gets implemented, no references are updated by `RefactorRename`, period. Only the implementing methods get adjusted.
Since we currently do not clean up sub and super classes when we r
> Not necessarily a typo...at least this is how I've used VBA interfaces in the past. The first line establishes what class is implementing the interface in preparation for the Set statement. If I had added the "I" in the first statement, calls to DoSomething() are forwarded to the interface defintion (empty proc bodies).
@Mat'sMug Well, C# has optional parameters and method overloading...
@Hosch250 @Mat'sMug Did you see this?
I could move the inspections and quick fixes into their own assembly, make the result independent of the quick fixes, make the inspections run on state changed instead of with the inspector, and more.
Then, I could add an AddInspectionAnnotation(result) method to ParseTreeNode, or whatever that base type is`, and add the results to the node as they are created.
And a List<IInspectionResult> InspectionResults member for the node too.
Then, in the inspection viewer, we could either walk the tree, or fire an event with the inspection result when we add it and update the view by listening to that (not sure if this is the best idea...).
there is no base type we can add that to. we need to implement some IInspectable interface on all annotatable ParserRuleContext derived classes that can be inspected
I think we can keep the inspector, it makes a nice place to inject IInspection implementations into - IMO the IInspector would become a dependency of the ParseCoordinator which would run the inspector when inspections are ready to run
And the next step is how we are going to manage asynchronicity. Are we going to inject the inspector/inspections into the parse coordinator, or are we going to pass the cancellation token as part of the state changed event?
@Mat'sMug That is where I disagree.
We are going to have other tasks that could/should use that token.
I don't see how. You still have to check for cancellation (or use the try/catch and throw when it is cancelled) in the inspector.
@Mat'sMug Yeah, sure, but it will still be running off the event.
In fact, that defeats the whole purpose, because I'm not going to have the refactorings, commands, etc. all wait until the inspector is done to become available. They currently update on Ready, but they'll have to start updating on Inspecting
we need to seriously think about that one - implementing an interface to extend single ANTLR-generated class is a MASSIVE undertaking, we don't want to be making major structural changes to that after it's done
Basically, we need to decide on two things: 1) how to handle cancelling a task--and I insist you make it scalable, because I won't refactor it for you later, and 2) whether to keep the inspector, or whether to make the inspections each responsible for themselves.
> FWIW - RenameRefactoring was free of unit tests for renaming controls (though it has code for for doing that). I added a RenameControl unit test and it failed in a similar manner as this issue (renamed declaration, left references as they were). I'm currently working on refactoring RenameRefactoring and am fixing these issues as I find them.
@BZngr one reasonlame justification whyRenameControl didn't have any tests is probably because it was implemented well before it was even possible to mock a UserForm, let alone form controls :)
Here's an interesting one. Reinventing the wheel or just pure ignorance?
What problem does this pattern solve that multicast delegates (a.k.a. events) don't? The framework's solution to the problem you're describing is to encapsulate the event args in an object derived from the EventArgs base class, so you get EventHandler<TEventArgs> as a generic delegate, with object sender, TEventArgs args as a signature. So... Indeed there's an established way of doing this: events! — Mat's Mug ♦9 mins ago
that one will end with a gigantic facepalm I think
#ConnectTheDots
I guess I shall have to look up events since your answer contains many terms I don't know. Thanks for pointing me in that direction though. — TheFaithfulLearner2 mins ago
meh, the guy was reading about design patterns, thought "Mediator" seemed like a very useful one, decided to implement it in C# without realizing that the framework itself implemented the pattern
this scares me
private volatile object locker = new object();
you don't understand events and multicast delegates, but you understand volatile? no way
It has to read it from the memory each time you access it because it might have been written to from multiple threads.
@IvenBach That's what makes it fun!
If you know where to look for the knowledge, it is easy to learn it. The hard part is finding something new to learn when you don't know what you don't know.
Well, people generally automate Excel with VBA, not C++. Doing that in VBA avoids many pitfalls you're getting to put up with in C++. I'd probably just generate a .csv file and use Excel to import it, and then pivot it perhaps. Or use VBA to lay it out as needed. But straight-up Excel automation in C++.... you're a brave warrior man! — Mat's Mug6 secs ago
I would like to repeat my point regarding the inspections. For better control of when the inspections start, I would prefer injecting the 'Inspector` or better an implementation of an interface IInspectionRunner into the ParseCoordinator that simply has a void method RunInspection.
This could have an overload taking the CancellationToken or an optional parameter with default value CancellationToken.None. It could also have an overload taking a Collection<QualifiedModuleName> to have an interface for running the inspections on selected modules only. How exactly they are run, how concurrency between them is handled and cancelling running the inspections would be a concern of the implementation of that interface.
BTW, I would actually like to refactor the ParseCoordinator quite a bit and pull the details of running the different steps into their own runners and inject them back. Than the Coordinator would truely only be responsible for the overall coordination.
"inspector" assembly (/any plugin assembly) would have a reference on the RD main assembly; as far as RD main is concerned, all inspections are just IInspection - there's no circular reference involved
wait no
damn, you're right
...
no - we wouldn't be referencing the plug-in at compile-time, but loading it at startup
Thanks for the downvote. Mind telling me what's wrong with this answer so I can improve it? /edit: added a note about not really needing to read the cell value into a variable. Hope I'm a good mind reader. — Mat's Mug8 mins ago
@M.Doerner had to... wouldn't compile otherwise :)
When we run the inspections from the coordinator and not anymore from the view model, which had been listening to the state ready event, we will probably need an inspections finished event the view model can listen to. As rightly remarked above by @Hosch250 another parser state is not really an option.
Moreover, we will need an IInspectionResultsProvider to inject into the view model, so that it can get the results.
That would just get the results from wherever we choose to store them, be it the parse trees or somewhere else until we have figured out how to annotate the parse trees properly.
that's why I want to discuss & document this: we need to decide which subclasses we want to implement IInspectable, and what IInspectable needs to look like
but yeah, some contexts have subtypes of their own; ExpressionContext would be one. in these cases we just make the base class implement IInspectable and we knock off all subtypes at once
I would still like to pass an interface IDataForInspecions to the inspections instead of the state to get a bit of separation between the state/parsing engine and the inspections.
well wait a minute - currently we pass these listeners and collect faulty Context instances, which we then assign to IParseTreeInspection implementations
VBA has a built-in functions for repeating a single character:
Function String$(Number As Long, Character) As String
Function Space$(Number As Long) As String
But neither are of any use when you need to repeat a string that has more than one character.
You could repeat a string "abcde...
I would like that this code would now be done in a faster way:
Sub TechMapping()
Set mappingWB = Workbooks.Open(Filename:="path\workbook1.xlsx")
Sheets("Sheet1").Activate
Dim Lookup_Range As Range
Set Lookup_Range = Range("A2:P1779")
Workbooks("workbook2.xlsb").Activate
...
VBA Rubberducking
VBA Rubberducking