Welcome Guest.   Make a donation to an author on the site October 30, 2014, 02:01:57 PM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Check out and download the GOE 2007 Freeware Challenge productivity tools.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: How do I Start a Ribbon Project?  (Read 3906 times)
Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« on: December 30, 2011, 01:32:32 PM »

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.
Logged
Ath
Supporting Member
**
Posts: 2,240



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #1 on: December 30, 2011, 01:51:33 PM »

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 smiley
  • 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
Logged

Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« Reply #2 on: December 30, 2011, 02:52:49 PM »

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? smiley) ... 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.
Logged
Ath
Supporting Member
**
Posts: 2,240



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #3 on: December 30, 2011, 03:06:16 PM »

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 cheesy

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 Wink
Logged

cranioscopical
Friend of the Site
Supporting Member
**
Posts: 4,182



see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: December 30, 2011, 03:43:36 PM »

My mistake  embarassed
Logged

Chris
Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« Reply #5 on: December 30, 2011, 06:32:35 PM »

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 cheesy

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 Wink

Okay... Me go start reading. smiley
Logged
wraith808
Supporting Member
**
Posts: 6,445



"In my dreams, I always do it right."

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #6 on: January 01, 2012, 01:46:51 PM »

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.
Logged

Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« Reply #7 on: January 01, 2012, 02:17:45 PM »

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... smiley

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.
Logged
EĆ³in
Charter Member
***
Posts: 1,400


O'Callaghan

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #8 on: January 01, 2012, 07:24:25 PM »

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.
Logged

Interviewer: Is there anything you don't like?
Bjarne Stroustrup: Marketing hype as a substitute for technical argument. Thoughtless adherence to dogma. Pride in ignorance.
wraith808
Supporting Member
**
Posts: 6,445



"In my dreams, I always do it right."

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #9 on: January 01, 2012, 08:55:39 PM »

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.
Logged

Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« Reply #10 on: January 02, 2012, 09:56:50 AM »

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.

 ohmy 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... smiley

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.  Kiss
Logged
Stoic Joker
Honorary Member
**
Posts: 5,344



View Profile WWW Give some DonationCredits to this forum member
« Reply #11 on: January 02, 2012, 10:33:08 AM »

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.
Logged
hintonrenata
Participant
*
Posts: 1

View Profile Give some DonationCredits to this forum member
« Reply #12 on: January 02, 2012, 03:03:20 PM »

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:
Logged
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.071s | Server load: 0.03 ]