How do I Start a Ribbon Project?

[Stoic Joker]

Okay, first of all, yes ... I have lost my mind.


I'm thinking/debating/toying with starting a project based on the Ribbon UI style interface. However... Historically I have always worked in straight WinAPI C++ (with a little pure C). So I've not a friggin clue how to even start a project based on the newer code forms.

Note: The project in question will be for integrating several disparate internal systems into one concise interface to speed up access to all of the relevant business data for the staff (e.g. I'm looking at having to do a complete rewrite of everything from scratch).

So... What am I looking at starting with, a Forms based application, .NET, MVVM? It's an insanely huge project, so if I gotta learn something new on the fly ... I really want/need to get the maximum bang outta whatever I jump into. Only "condition is that I'll be using MSVS of what ever version is/would be best ... which is (i guess) the other question; do I need to move to MSVS2010, or will 2008 do...for creating a (MS native code) Ribbon based UI for the application framework.

Side Notes:
Tablets are getting popular at the office, so I'm looking to do something "Finger Friendly".
There may be a limited access web interface involved (IU consistency issue).
This is a Window Only Environment.

[Ath]

A few tips (in random order):

• Get VS2010, (and upgrade to VS v11/2012 as soon as it arrives) "The latest is the greatest" counts triple for MS dev-stuff
• MVVM is good for a big any project, if MVVM is the right pattern to use...
• WPF/XAML is what a ribbon UI is built upon (and you need at least VS2010 for decent XAML support)
• With a C/C++/Java/Pascal/Cobol (read: non-VB) background I'd opt for C# as the language, only choose VB.Net if that's what earning you a living already (no war please, just being practical).
• Read the Ribbon UI 'guide' on MSDN before you do anything with a Ribbon UI

[Stoic Joker]

I tried jumping from MSVS2005 to 2010 and it annoyed the hell outta me (forget why), so ended up backing up to 2008 (which is what my NANY Got Space was done with). I tend to be trepidative with new Dev stuff ... But had a feeling that going Ribbon era UI would require 2010. Is the ribbon patient crap still going on?? Or will MSVS2010 natively support the damn thing. I just spent an hour trying to figure out how to get the damn RibbonControlsLibrary.dll stuck some where so I could compile a code sample.

Even though my last/first experience with C# went badly... I had already resigned myself to having to go that route ... I fiercely detest VB with every fiber of my being, and would rather quite programming than switch to that nonsense.

Is the Ribbon UI guide the one where it goes over when you should/shouldn't use one? Because that particular detail will most likely be decided by a committee (I bet you just said F***, didn't you? ) ... Don't worry it's a small very bright committee (and I have trump...).


My primary objective is to get started with the newer, slicker (looking) IU for the project ... And to make sure (from the start) that it is willing to be fingered without forcing the user to futz with a bunch of foreplay.

[Ath]

My primary objective is to get started with the newer, slicker (looking) IU for the project

Then Ribbon UI should be a part of your WPF based interface stuff

Yes VS2010 is the only route if you are going to do WPF/XAML, all previous version suck at that.

Maybe WPF is what you should start at, and drop in a Ribbon as the Menu replacement, as is often done, the semi-official guide to WPF is Josh Smith, with Sacha Barber as a good complement

[cranioscopical]

My mistake 

[Stoic Joker]

My primary objective is to get started with the newer, slicker (looking) IU for the project

Then Ribbon UI should be a part of your WPF based interface stuff

Should be, yes. But is it in 2010 ... It isn't in 2008.

Yes VS2010 is the only route if you are going to do WPF/XAML, all previous version suck at that.

Had a feeling about that ... Thanks for the confirmation.

Maybe WPF is what you should start at, and drop in a Ribbon as the Menu replacement, as is often done, the semi-official guide to WPF is Josh Smith, with Sacha Barber as a good complement

Okay... Me go start reading.

[wraith808]

Sorry for jumping in late- I've not been following the boards closely while I've been on vacation.

The preceding is incorrect.  You can do wpf with VS2008 (I started learning with VS2008).  

A good article on getting started with WPF in VS008 can be found here.

You can also do Ribbon with WinForms. A project on codeplex wraps this up here.

[Stoic Joker]

Sorry for jumping in late- I've not been following the boards closely while I've been on vacation.

The preceding is incorrect.  You can do wpf with VS2008 (I started learning with VS2008). 

A good article on getting started with WPF in VS008 can be found here.

You can also do Ribbon with WinForms. A project on codeplex wraps this up here.

Hay, better late than never they say...

I think the point made above was in regard to XAML handling being better in 2010 *Shrug* I've never used it so I'm really just looking at/for the best entry point. I'm actually a bit on the fence about the Ribbon UI...still toying with it...but (after playing with some sample code/projects) more focused on a side issue at this point. That being, it seems that the WPF doesn't support (and rather shuns) the MDI interface. Which is a rather important sticking point for what I'm planning on trying. It's a business management application ... So it really kinda has to be a MDI so users don't have to contend with lose windows scattered all over the desktop while looking up multiple clients/products/contracts/etc.


So far two things have occured to me:
1. This probably a stupid idea.
2. It has to be done.

[Eóin]

Going WPF means going C# or C++ CLI I believe. However you don't need to go managed .NET for the ribbon, it is exposed as a native Win 32 API.

I would suspect the easiest way to start a ribbon project is through C++ WTL and this tutorial - Relook your Old and New Native Applications with a Ribbon UI under Vista or Windows 7 (WTL)

I admit my soft spot for WTL does bias me in that suggestion. But being a header only library which wraps the WIN32 APIs, it means you acquire zero external dependencies.

[wraith808]

It's a business management application ... So it really kinda has to be a MDI so users don't have to contend with lose windows scattered all over the desktop while looking up multiple clients/products/contracts/etc.

I've done something like this in SDI with WPF, and it actually turned out better once I got rid of my preconceptions. 

Two things I did to make window management simple:
1. The windows are aware of the other windows and there is a menu that allows you to select the other windows from that window
2. There is a launch application that everything is launched from, which also has an icon in the tray notification area.

How this helped and became a help rather than a hindrance:
1. They each run in their own process
2. All of the client machines have two monitors, so the MDI interface that they were used to actually limited their ability to position windows; they used to run two instances of the application.
3. They all are upgrading to windows 7; the positioning abilities of windows 7 actually made the layout more versatile.

So I'd say don't limit yourself by the classic UI, but look at the options and find out what actually works best for the client.

[Stoic Joker]

Going WPF means going C# or C++ CLI I believe. However you don't need to go managed .NET for the ribbon, it is exposed as a native Win 32 API.

Now that plays rather nicely on my weakness for the native Win32 API ... I had initially anticipated that this project would entail jumping directly onto a C# object because the API wouldn't fly. That could very well be the best news this project ever gets...

I would suspect the easiest way to start a ribbon project is through C++ WTL and this tutorial - Relook your Old and New Native Applications with a Ribbon UI under Vista or Windows 7 (WTL)

Okay, So... What kind of shenanigans would I have to go through to access/use the newer (XAML) style interface/controls if I go the WTL route...or is that even possible?? I'm kind of making a point (with this project) to step away from my comfort zone classic (made for Win95 look) UI, and do something along the lines of some of the newer more (trendy?) current UI's that aren't quite so (Win95-esq) starkly utilitarian.

(I do hope I'm explaining this right - I'm just not entirely sure what half this new crap is called)

I admit my soft spot for WTL does bias me in that suggestion. But being a header only library which wraps the WIN32 APIs, it means you acquire zero external dependencies.

And on that note I'll have to go outside and do cartwheels. 

[Stoic Joker]

It's a business management application ... So it really kinda has to be a MDI so users don't have to contend with lose windows scattered all over the desktop while looking up multiple clients/products/contracts/etc.

I've done something like this in SDI with WPF, and it actually turned out better once I got rid of my preconceptions. 

Two things I did to make window management simple:
1. The windows are aware of the other windows and there is a menu that allows you to select the other windows from that window
2. There is a launch application that everything is launched from, which also has an icon in the tray notification area.

How this helped and became a help rather than a hindrance:
1. They each run in their own process
2. All of the client machines have two monitors, so the MDI interface that they were used to actually limited their ability to position windows; they used to run two instances of the application.
3. They all are upgrading to windows 7; the positioning abilities of windows 7 actually made the layout more versatile.

So I'd say don't limit yourself by the classic UI, but look at the options and find out what actually works best for the client.

Understood, I've got an IMS MDI that I did for the production department that has worked out rather well. But it was a native Win32 API app that took bloody forever to do ... Which I'd like to avoid, by leveraging some of the newer rapid development - App Framework handled by "Magic" - methods that are available these days. Assuming I can get my head around it fast enough to get the project off the ground fairly soon (eek!).

Note: (good news/bad news) This will be an in-house project so i/we are the client. We have several disperate systems that were designed for specific unrelated projects ... That are now directly related and need to be sharing data instead of (enducing errors by) duplicating it. The also aren't scaling well so I'd like to (take them all out and shoot them) start over from scratch with current design requirements...before it becomes a complete maintenance nightmare.


Anyhow... I ran across an interesting code sample over at CodeProject, that is a MDI UI that allows children to be pulled out of the main window and docked. Multiple Window Interface for WPF Being a fan of have your cake and eat it too solutions ... I'm leaning that direction. (And Eóin's above bombshell is pulling hard in yet another direction.)

But nothing is carved in stone yet. I've still got to meet with the brass to get the project approved, and discuss what the user access requirements actually are. There is a small possibility this may need to be (or at least have) a web interface for the road warriors.


Oh yeah, we still have many XP machines, and everybody is single monitor. They're at least (mostly...) wide monitors...but they're all singles.

Main thing I'm after is a single click to close functionality, so it isn't constantly ophaning child windows/processes like our other BM software Sage BusinessWorks. That nightmare takes an act of congress to completely kill for restart when (not if...) it crashes.

[hintonrenata]

Add Reference to Wpf-Ribbon assembly to your project

   In C# right-click References node in Solution Explorer and choose Add Reference context menu command. In the Add Reference find and select DevComponents WpfRibbon and click OK.
   In VB double-click My Project node in Solution Explorer and click on References tab. Click Add button and in the Add Reference find and select DevComponents WpfRibbon and click OK.

You should already have the default WPF Window created by the VS.NET so open the Window1.xaml and change the Window declaration to: