> Version 2.4.0.4533 OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64 Host Product: Microsoft Office 2013 x86 Host Version: 15.0.5093.1000 Host Executable: EXCEL.EXE
**Description** Context menu attempts to be displayed when right click is used on grouping header before any item is selected.
**To Reproduce** Steps to reproduce the behavior: 1. Have code that will show for as an inspection. 2. Right click on a grouping header. Tiny context menu attempts to show but nothing is a
The actual rewriting in the code panes will be easy to handle via the `IAnnotationUpdater`.
One correction though: there are multiple commands taking multiple strings as input, e.g. `ModuleAttributeAnnotation`. In that case, even the number of arguments is not fixed. (BTW, you can have arbitrarily many of these on the same module.)
Why are you "wrapping" a worksheet behavior in a class like that? A worksheet is already a class. TBH, I'm surprised this isn't crashing Excel. When you show the form vbModeless, it separates it from the Excel message pump - that means you have a whole bunch of asynchronous events firing from Excel when you start messing around with it's objects inside of a class constructor. It may be best to describe what you want to accomplish, scrap this access violation waiting to happen, and rethink the architecture. — Comintern20 secs ago
I've created a code that works, but takes time to run.
Is there any way of making this code work in a more efficient way?
In short terms I want to:
make a new copy of sheet 1 and 2
Select the row with lowest value in sheet 1
Paste this row in sheet 3, and select item-number, rownumber and OP-...
> This PR is no longer WIP. I would appreciate any feedback. In particular, I would be interested to know whether I overlooked something important in the redesign of the `MoveCloserToUsageRefactoring`.
In addition to the issues highlighted in the OP, we should consider cleaning up the key names. Because they came from a single huge resx originally, they had a prefix in the key name which now look very redundant now that we have a specialized .resx file. Those should be stripped out to make the already long names somewhat shorter.
@Duga Actually it's R# being dumb. I always have to "enable C# 7.{1|2} feature" everytime I open up a file that has such feature to turn off the misleading red squiggles. It seems to not remember the setting and does it on a per-file basis.
I'd like to know that myself. Currently, when I see such red squiggle, I just use the context menu to enable the language feature. But that only works on a per-file basis.
yeah, they realized it was just a big mess to tie into a specific version especially that there are much more collaboration, which may not be on the same version.
> I disagree if I understand the issue being raised; the vanilla VBE does support copying a module from one project to another:
Clicking and dragging a module in the VBE Project Explorer from one project to another will indeed accomplish a Copy/Paste from one project to another. I wish CE had that capability.
Admittedly, it is a single module at a time, but still it can be done.
From: bclothier <notifications@github.com> Sent: Thursday, February 14, 2019 6:53 AM To: rubberduck-vba/R
> I disagree if I understand the issue being raised; the vanilla VBE does support copying a module from one project to another:
Clicking and dragging a module in the VBE Project Explorer from one project to another will indeed accomplish a Copy/Paste from one project to another. I wish CE had that capability.
Admittedly, it is a single module at a time, but still it can be done.
TBH I am still having mixed feeling about the idea anyway - I don't want encourage copy-pasta in a language that apparently lends itself to .... copy-pasta.
Because I originally was thinking about keeping the internal state -- the module level variables -- private. I would actually end up redoing all the public stubs and revise some of the variables but keep the setup/teardown within the class Initialize/Terminate events.
e.g. implementation B has some extra considerations that requires changes to the internal state. I wouldn't want to change the shared "state" class for that.
> I guess I am a bit ambivalent about copying within a project. It would seem to me to suggest that if it is all that useful to “copy” everything in a module (within a project) it is likely a better candidate for refactoring and generalization of the common elements.
There are many times that I want a “toolbox” of stuff in a project. Being able to copy from one to another in the PE is something I use reasonably often. But then, I am nowhere near as sophisticated in my development as others a
> I guess I am a bit ambivalent about copying within a project. It would seem to me to suggest that if it is all that useful to “copy” everything in a module (within a project) it is likely a better candidate for refactoring and generalization of the common elements.
There are many times that I want a “toolbox” of stuff in a project. Being able to copy from one to another in the PE is something I use reasonably often. But then, I am nowhere near as sophisticated in my development as others an
I would hope that you'd fail a bunch of other tests if your properties weren't connected to the backing fields correctly. About the only thing I'd test is if they were initialized in the ctor.
Hmm. I was trying to explain why Initialize isn't like a ctor and I now need a sanity check -- in C# ctor, we can call stuff outside the class being constructed, right?
the way I see it, a VBA class inherently inherits a base ClassModule class, whose default ctor fires an Initialize event, and whose destructor fires a Terminate event, that the inherting class (i.e. the user code) can handle - Class_Activate is an event handler, not a construtor.
@this Looking at it another way though, you could conceptualize it as the base ctor having run first, and the Class_Initialize being the derived constructor. Since VB is single threaded, it will deterministically be the next call after the class is created, so at that point isn't it just semantics?
Although playing devils advocate, you can call DoEvents in Class_Initialize. We should have an inspection for that.
I know there were few more examples where the behavior weren't necessarily the expected - Unfortunately, I did not take careful notes when I encountered those. Here's a different example, though:
Class2:
Private WithEvents c As class1
Private Sub c_Load()
Debug.Print "Loaded"
End Sub
Private Sub Class_Initialize()
Set c = New class1
End Sub
Class1:
Public Event Load()
Private Sub Class_Initialize()
RaiseEvent Load
End Sub
There was also a different instance where having errors thrown in the constructor don't always prevent the creation of the object. However, I tested that and in simple scenario, it does work (e.g. the object is not created as expected). But it did happen on one project I worked and they had created a "singleton" class that did not actually work the way they thought (the object gets created anyway)
it might have had more to do with the error handling stacking, though.
That might be more of an issue of the order in which the Set c = New Class1 runs vis-a-vis the WithEvents. Doesn't New Class1 have to return there before the assignment to c happens?
That means the event source isn't hooked up until the call to New fully returns.
There simply isn't a listener connected until after Class_Initialize has completed.
Apparently we need an inspection for that too.
ClassInitializerInspections is rapidly wanting to be in a folder...
I've created a code that works, but takes time to run.
Is there any way of making this code work in a more efficient way?
In short terms I want to:
make a new copy of sheet 1 and 2
Select the row with lowest value in sheet 1
Paste this row in sheet 3, and select item-number, rownumber and OP-...
VBA Rubberducking
VBA Rubberducking