xsharp.eu

Although in general I am not a fan of the ribbon, I now do have 1 program where it would fit in perfectly. After some testing I have a pretty usable situation but there's one thing I was wondering. Couldn't find it anywhere so maybe someone here knows?

In VS 2019 Design Mode I see the controls on the first tab. However, I never see how the next tabs look like, also not when I select the XAML code of a control in one of the next tabs. Only when I compile & start the program I can see the result.

Does anyone know if this can be done, and how?

Dick

Hi Dick

I can’t answer your question directly, but if I understand you correctly, I would suggest that what you are asking for cannot be done.
The fact is the Ribbon is somewhat of a double-edged sword. It imposes a consistent “look and feel” across all types of application, and in terms of the “way of doing things” requires a degree of intuition.

To achieve this, in operation panels etc, overlap each other and so on – complex code-behind logic.

I have approached things from a coding perspective (C#). Developing the Ribbon in conjunction with the underlying program it is controlling. I found this easier since the look of Ribbon Buttons, Drop-downs can be easily mentally visualised as you go. The coding is not too difficult with Ribbon-this and Ribbon-that and knowledge of how WPF goes about things.

The C# code maps easily to XAML.

As for actually “seeing” the end result, I have found that compiling and running without debugging can take timescales in the region of 1sec. (including time to press the key!)
If you need to debug a bit longer (5 secs?).

This is of course just personal preference and I am using a fairly fast machine.

The Ribbon can be integrated into your development system as System.Windows.Controls.Ribbon and System.Windows.Controls.Ribbon. Primitives. Be careful using intellisense as it may change references to the Microsoft Ribbon which has differences. (Don’t know what they are other than different namespaces.).

HTH
Terry

Hello Terry,

It's indeed not too much work to check after compiling. Especially as you can't influence the positioning too much. Controls within a ribbon behave like placed in a stackpanel, where Windows/WPF determine where they are placed. Add just 1 point to a height and all remaining controls may move up to the next column.

It shows however, once again unfortunately, how disappointing VS works. If Robert & Chris would have written the VS Design cod they would not have settled for tabs which you can't see in the design mode. Even in 25+ old VO, you can double click on a (window) tab and see the full content of that tab window. But nothing like that seems arranged in VS, for Ribbons.

I agree that a ribbon can be handy. In Office I found it a step backwards from the regular menu's in Office 2003. But with not too many options which could do with some separation it is handy. You now see that quite some smaller Microsoft apps use the UWP approach where no menu's (or maybe a hamburger menu only) are used but icons are placed on the upper and or lower side of the app.

Another proof of the inadequate working of VS was that when I moved my ribbon XAML from the test to the existing app I got this error:

XDG0008 Ribbon is not supported in a Windows Presentation Foundation (WPF) project

The VS programmer who programmed this error was apparently a starter :unsure: . What I had to do was add a refence (using browser) to C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5System.Windows.Controls.Ribbon.dll.

This had another side effect, proof 3 of VS' lack of quality. I got:

Unknown build error, 'Method 'get_Command' in type 'System.Windows.Controls.Ribbon.RibbonSplitButton' from assembly 'System.Windows.Controls.Ribbon, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' does not have an implementation.

No idea (yet) why just one control used (and working) in the test program, the RibbonSplitButton, gives this error (and what it means...)

Although in the X# field there are things left to be desired, and every now and then something is reported as not working (well) these 3 simple experiences show how big the achievement is of the X# team compared to the much larger Microsoft teams.

So if anyone has a choice of getting a Fox program or some Microsoft program: add a Fox program!

Dick

Hi Dick

Can't disagree with what you say, but can't help feeling you're being a bit harsh in respect of VS. Overall it is addressing a far broader range of application types and so on, than would ever be the case in the FOX arena.

Things are always a balance, and whether MS has got the balance right in this case is open to question.

Terry