> **Justification** While working I quite often drag and drop by accident and it just wastes time.
**Description** So I am not entirely sure why I do this, if it is because the UI is just laggy enough or it doesn't always register mouse up before I have moved, or if I am just a sloppy mouse user. Regardless the result is that I have to undo that operation when I do it by mistake.
There are a few number of ways to fix this that I can think of: * Add an option to simply disable drag and d
> Oh sorry, should have clarified. Dragging and dropping folders and modules in the Code Explorer with the new drag and drop feature introduced somewhat recently.
> **Rubberduck version information** Version 2.5.0.5457 OS: Microsoft Windows NT 10.0.18362.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.12730.20270 Host Executable: EXCEL.EXE
**Description** After adding a User Form to Personal.xlsb RD has a Parse Error.
**To Reproduce** Steps to reproduce the behavior (assuming it can be reproduced): 1. Add a new UserForm via RD CE>Add>UserForm to Personal.xlsb 2. See Parse Fail with Personal.UserForm1 in banner
I’m Ham and I’m a developer on the Teams team here at Stack Overflow. Over the past few months, I’ve been heads down working on the way we turn Markdown into HTML when writing and editing posts across the network. I’d love to share what I’ve come up with.
In a nutshell: We’re planning to use Com...
So I'm finding some interesting things in my research into VBA internals
The notion that editor code is converted into p-code every time you press enter on a line is not quite accurate
It seems there's a couple of different encodings going on
First up is an "editor format" encoding, which is what pcodedmp decodes. It's quite close to source, with most of the opcodes mapping 1:1 with VB keywords. Literals are extracted and stored in a mapping table to save space.
Then there's the actual p-code, which gets created when you compile. It represents the actual instructions for the VB VM, and I think is what bontchev has called "execode". IIUC, that's the only thing that that "VB Obfuscator" thing leaves in place.
The VBE cannot roundtrip actual pcode back to source (I haven't found anything that can yet, other than Wayne's recovery service)
It has 1159 opcodes in VB6, although many are duplicates
Still chasing pointers though to try and find where it all is in mem.
@Vogel612 Tbf it's not just encoding VB keywords, but also operators, some "built-in" functions, and some ops for variable handling.
example form pcodedmp's readme:
Private Sub Document_Open()
MsgBox "This could have been a virus!", vbOKOnly + vbInformation, "Virus!"
Shell("calc.exe")
End Sub
tranlsates in editor format to:
Line #0:
FuncDefn (Private Sub Document_Open())
Line #1:
LitStr 0x001D "This could have been a virus!"
Ld vbOKOnly
Ld vbInformation
Add
LitStr 0x0006 "Virus!"
ArgsCall MsgBox 0x0003
Line #2:
LitStr 0x0008 "calc.exe"
Paren
ArgsCall Shell 0x0001
Line #3:
EndSub
I know that VB6 has a "second stage compiler" called C2.EXE that takes intermediate files from the built-in stage 1 compiler and does futher stuff. Yet to investigate that.
It's possible it's responsible for pcode -> native, but at this point that's just a guess.
though, passing "" into an API could result in some interesting firework or at least an unexpected result.
So arguing that "" shouldn't be used because it wastes space will ring hollow but consistently representing a empty string with a null pointer is a more compelling case.
I also found out why some objects like Screen are special little soldiers. There's a flag in the VBHeader that tells the runtime to initialise them automagically.
wow the donations keep coming, $5 here, $10 there, EUR, AUD, CAD, USD, ...it's beautiful. I need to get the receipts and add things up, but if 2020 hosting isn't covered, it's sure getting close!
> I would like to close this PR in order to split and resubmit the functionality with two PRs.
1. A `ConflictDetectionSession` PR. This would propose the `ConflictDetectionSession` capability and the associated removal of conflict detection code in the `DeclarationFinder`. 2. The current `MoveMember` PR would be then re-submitted after modified with the outcomes of the `ConflictDetectionSession` PR and PR #5452.
I am hoping that this is a better approach. And, will make the review proc
> **Rubberduck version information** Version 2.5.0.20863 OS: Microsoft Windows NT 10.0.18362.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4978.1000 Host Executable: EXCEL.EXE
**Description** Root cause is unknown. Intermittent as to when it shows. Started getting this unhandled exception after adding a lot of properties to a worksheet and unit tests.
**To Reproduce** ---Steps to reproduce the behavior:--- Will document if problem perists and can determine cause.
btw, I thought of a decent use-case for understanding the VBA internal memory layout. With full comprehension, it should be possible to provide an explorer for breakpoints and bookmarks, the absence of which is often lameted on the internets.
And less easily, save / restore across sessions (restore could be a problem, don't really want to be writing to the same memory as the VBE...)
> The root cause of this issue seems to be the virtualization applied to the TestGrid having a bug in the height-calculation.
As it is currently, our code is only adding a new item to a collection [here](https://github.com/rubberduck-vba/Rubberduck/blob/37bd1bb1276854b0757e6a300e5845fc8d941ff2/Rubberduck.Core/UI/UnitTesting/TestExplorerModel.cs#L230). This triggers the insertion of a new row into the GroupingGrid's underlying ListView, where the VirtualizingStackPanel seems to break upon reca