Is there a way to control the toolbar?

[GTMxCode]

Just wondering.. Ive literally scoured every part of the documentation provided.. Is there a way to have the toolbar STAY where I put it? I realize that its dynamic and extends and contracts depending on context so I'm not going to want other toolbars right up beside it, but every time I load VBE, there it is on top left in the third toolbar row, on its own once again. It doesn't seem to matter where I put it or what I put next to it (or nowhere near), it always ends up back in this same location every time. Ive even tried customizing it by sticking its elements beside the menu bar and discarding the toolbar

At this point I havent tried just leaving it floating.. but ugh I really would rather not do that. Please tell me there is a setting Ive overlooked? Please?

Thanks

[retailcoder]

Having it at the same specific location at startup is how we can control tame the toolbar. The VBE will just put it wherever it wants otherwise (toolwindows showing up at random sizes and random locations is a good "preview"), and drive everybody nuts - leaving it alone where it's at is the single least-pain way to go about this.

What we needed was a status bar, alas.

Curious, where do you put it / what's wrong with where it's at?

[testingoutgith1]

@retailcoder What do you mean by "status bar" as distinct from a VBE toolbar?

[retailcoder]

Yes. The VBE doesn't have a status bar at the bottom, like Excel or Visual Studio do. If it did we wouldn't need to hack one up with a commandbar =)

[testingoutgith1]

@retailcoder Envisioning the day RD completely replaces all major functionality of the VBE...

[testingoutgith1]

Though in the interim I am curious, how difficult would it actually be to have a setting to tell where the command bar should be during initialization?

[Vogel612]

@testingoutgith1 the setting itself wouldn't be all that much of an issue, the more interesting question is: what values should the setting allow? And how can we make sure rubberduck can start, even if the setting has a nonsensical value?

I think the danger to the startup process there is considerable and I wouldn't really want to implement the setting while there are features and issues that affect more users :/ That being said: if you implement such a setting, I'm sure we can pull that into the ducky :)

[testingoutgith1]

I sometimes feel that questions without an obvious or technically correct answer are the real hard part with programming. l'll take a look at the startup process and see if I can answer these ones easily enough to justify putting effort into implementing it.

[mansellan]

The Office CommandBars (which all VBA editors use, even non-Office hosts) are flakey at the best of times. When interoperating with C#, especially so.

Currently, the status bar (and iirc the RD main menu) are added as "temporary", so they're created each time RD loads and destoyed every time it exits. Ideally, they'd be permanent, which should mean that their locations persist and also (for the few people that know how) they can be customised with the VBA toolbar editor.

As others have noted though, this opens a big can of worms in terms of COM cleanup, predictability and how we can recover from corrupted states.

[retailcoder]

Correct. We've spent the better part of two years struggling with proper tear-down of that darn commandbar - "reluctant" doesn't even begin to describe how I feel about changing this. Last thing we need is to deal with access violations on exit again.

[testingoutgith1]

This makes sense to me given my general experience working with COM. I guess my only thought is that the location the command bar is created could be stored in a setting? So it would still be temporary as needed to avoid the issues but would appear "permanent" to the user.