Refeshing in the code in VB6 reformats the whole file for source control

[mika76]

VB6 has always been weird that if you open a form it basically reformats and moves controls around in the file. At least this is generally how it is with our (pretty large) codebase.

Turns out that when I click refresh on Rubberduck in VB6 IDE it opens and reads in all the files, and in turn those form files all become reformatted and basically changed for source control.

We're using TFS in case this is necessary info.

Anyway, Is there any way around this? I tried searching through the issues but did not seem to find anything although it's hard to know what keyword to search for.

[retailcoder]

That's an artifact of the VBIDE API / the internal functionality that exports MSForms designer data is where the bug would have to be.

Rubberduck could of course intervene: it would have to parse the designer files and properly understand them to rewrite them reliably - there's a vast wealth of knowledge on the subject, buried in the catacombs of this repository's issues history... I vaguely recall of a discussion around this, and the decision to drop the idea because there wasn't really anything else to gain from parsing the designer files; back then we were focusing on the completeness and correctness of our grammar and identifier resolution logic.

Rubberduck 3.x might change that... 3.0 will very likely still use the native VBIDE MSForms designer, but at one point or another having our own editor is going to make it itch to implement a better forms designer. There's still a lot of blur and conditionals in that area so I'm not going to commit to anything, but ideas floating around include:

• Delegating the forms designer to twinBASIC, which has interesting implications but then I believe (I know nothing) the forms would have to be a binary blob to work with VBA, which isn't nice for source control.
• Introducing a MVVM UI framework of our own making, changing the paradigm of UI design in VBA by eliminating the need to interact with MSForms: the UI could be fully specified in generated designer code, or specified in any format (XAML-like?) that can generate the UI code. Event handlers become command bindings, input validation is simplified by several orders of magnitude, 2-way property bindings automatically keep ViewModel and UI controls in sync, ...and there's just an empty UserForm to export - so no control metadata to mess up.

I like the MVVM library approach very much, because it solves so many annoyances of working with MSForms in VBA, literally brings a new paradigm to the language, and pushes its users into a "pit of success" where doing things right is simply the easiest and most obvious thing to do.

Does little to address existing forms though.

[mika76]

Hey @retailcoder thanks for the reply.

Delegating the forms designer to twinBASIC

Honestly I don't really like the direction twinBASIC has taken (mostly the bundled project blob files you mentioned and the fact that it's moved away from vscode) so I don't think I'll be using it much in the future.

...is going to make it itch to implement a better forms designer

The forms designer in VB6 is probably the thing that irritates me the least. I am far more irritated by the code editing and that certain text editing features are missing. You guys have done amazing things by including references and searching in Rubber duck but multi cursors, easy in-code find/replace, highlighting words, etc... All those things are kind of missing from the text editor (incidentally the things which are again missing from twinBASIC because they chose not to use vscode) those things are the larger paper cuts to me.

Does little to address existing forms though.

I was more wondering why does VB6 even have to actually open the form files if rubberduck needs to parse them? Is rubberduck using the object model or is it parsing the text. If it's just the text then maybe the files could be opened in another process or something and then VB6 IDE wouldn't change them.

Or maybe another option would be to save a copy of the text, let VB6 and rubberduck parse them, then replace with the old text again? (The issue might be the references might be pointing to the wrong positions considering VB6 changes the file structure - but maybe not?)

Do you know at all why the files change in the first place? It's always been weird for me - I would have thought they would sort the controls by visibility or something and then that wouldn't change.

[wqweto]

All those things are kind of missing from the text editor (incidentally the things which are again missing from twinBASIC because they chose not to use vscode) those things are the larger paper cuts to me.

No, TB is using the same Monaco Editor that VS Code is using (inside a WebView component) so the editing experience is on par with VS Code. It is the pluging story (and other integration ones) which is currently missing but they plan on porting/returning to VS Code at some point so there are no worries about this one.

[mika76]

the editing experience is on par with VS Code

I regularly try twinBASIC and no, it's not even close to par with the vscode no matter what it says on paper.

they plan on porting/returning to VS Code at some point

I have not read that anywhere - in fact I brought up the issue on their github twinbasic/twinbasic#458 a while ago but no official comment.

[wqweto]

I regularly try twinBASIC and no, it's not even close to par with the vscode no matter what it says on paper.

If you did this then why you mention "multi cursors, easy in-code find/replace, highlighting words" is missing from TB editor?

I just tested multi cursors and highlighting words, not sure how easy find&replace is though.

[mika76]

Ah I think editing my comments got things conflated. Those comments were meant about the VB6 IDE code editor which I was talking about at that point. I'll strike it out.

But please, I don't want this discussion to be about twinBASIC, it's just going to overshadow the actual reason I created it which is VB6 IDE, Rubberduck and the form files which keep changing when opened.