I am in the process of learning WPF so please keep the answers as basic as possible. I am mediocre with VB.NET and an absolute beginner with WPF.
I am attempting to build a light Catering Kiosk Application using WPF for a Special Needs School. It will have 3/4 tabs at the top for the courses(Starter, Mains, Dessert) depending on the day of the week. Each Tab will change the Menu Options which is a horizontal picture list on the screen. On Selecting a Menu Option, it should populate a picture list on the right hand side of the screen acting as a summary of orders. On pressing the menu option, an audio should play in the background (Name of the item for visually impaired).
The menu is decided at the beginning of the day by people not very used to PC's so I am considering to build the app to read the days menu from a Directory where 3/4 folder depending on the number of courses for that day. Each Folder would contain Sub Folders with the name of the Menu Item and an Image and Audio File within it.
I am hoping that the Application on Load would check the Directory for how the it is arranged for the day and would populate the contents accordingly.
Some WPF snippets that have caught my eye are :
'itemsControl Class', 'Style Resource'
Thanks for all your responses in advance,
Ajmal
Personally, I'd just make it a VB app, Windows Forms Application and code the functionality you describe in your post. Use the TabControl for the (Starter, Mains, Dessert). Look at the PictureBox control to show an image on the right side etc. Side note, you working with the special needs kids is quite admirable!
Related
new to codename one, and I'm looking to build a fairly robust app. I've read a lot of codename one documentation and have looked through many of the demos on git. My question is, what is the best way to architect the application?
Here are my basic requirements:
Splash screen
Lock screen (enabled/disabled by user)
Sliding (hamburger) menu
Contents of sliding menu will change based on current 'form'
Application settings
Based on this short list of requirements, would it better to make each different screen a form, and the sliding menu for each a different 'instance', or make a main form that contains the sliding menu (and just change contents of menu based on current screen) and make each different screen a component instead of a form?
Also, I was considering coding it by hand, and not using the gui builder.
Thank you.
Greg
I would go with separate forms mostly because of the hassle of updating the side menu for every selection you make. This would also make the general design more flexible.
So I have this old PowerBuilder MDI application (medium enterprise app with about 40 windows), and I'm embarking on designing my very first WPF MVVM C# application to replace the aging PowerBuilder app. I've got plenty of C# & .NET experience, but this is my first WPF & MVVM app.
After reading many forum postings after searching for WPF & MDI alternative, I've come to the conclusion that the MDI isn't supported, and that the most commonly proposed substitute is to use the TabControl and dynamically generate the content of each tab page upon demand using a WPF User Control. I had initially been sold on this, and was actually excited by my initial prototype interface with a tabbed Ribbon bar at the top of the app, and the TabControl with the tabs of the app underneath that. However, I have hit a BIG brick wall.
Take a look at the following screen shot of one of the central multi-tab windows from my old application: http://www.creativedatatech.com/downloads/screenshot.jpg
As you can see, the app has a toolbar across the top and the left side, and the example MDI child window (Case Edit Window) that is open has a LOT of tab pages (18 of them), and the users really like being able to quickly click on a tab page to get directly to that information to work on it. Moreover, the users have grown accustomed to being able to open multiple Cases at once and either put them side by side (large monitors), or flip back and forth, possibly copying & pasting between them.
The problem here is that I cannot envision how I am going to incorporate all this multi-tab user experience for the Case Edit Window into a single tab of the top level WPF TabControl. Will the users end up seeing a row of tabs for the WPF TabControl, with one tab for each Case Edit Window that is open, and then inside each "Case Edit" tab page, a further nested set of 18 tab pages?? This seems confusing and a big mess of nested tabs. Add to that the tabs of the Ribbon control at the top of the app, and I think my users will be running after me to lynch me!
After investing two straight weeks reading up on WPF and MVVM, I am left with the sinking feeling that WPF really isn't going to fly well for enterprise apps such as mine.
Surely this can't be true! Does anyone have any comments on how I should go about shaping this app to accomplish what I'm trying to do here? I've already looked at WPF "pages", but I can't have the users serially navigate through all the individual pages to get to the content that they need to work on, and they need to be able to quickly (and visually) navigate to the Case Edit Window content that they need.
I think your problem is not so much WPF, but rather that GUI paradigms have moved away from the MDI that your current app uses. There is nothing stopping you implementing MDI in WPF, but what would be the point if your app ends up looking like it does now?
You really need to think about how to layout your app in a modern way. Perhaps you could keep your tabs for the different cases, but replace the multiple tabs in each child window with a master/detail view, much like Dev Studio does for its Options dialog?
We had this same dilemma, we decided on screen tabs at the bottom with tabs that relate to that screen at the top - and contextual ribbon items.
The tabs in the screens actually just scroll the window to the desired point so all information is sectioned off and available on each screen by scrolling or clicking the tab at the top.
Looks like this
I'm not too familiar with silverlight, so I'm pretty sure I am asking a basic question.
Is it possible to have a silverlight dropdown menu (like superfish, or so-called dhtml menus) in a web page that will ;
not use more space in the page than
the first level
will go over html content when we
expand it.
I guess that Silverlight has to be displayed inside a certain "canvas" like flash, so the silverlight menu has to be either :
as big as the fully expanded menu can
be -- with the possibility to display
html over it (using css?) and make
sure that the expanded items goes on
top of html ==> That seems not really
easy!
as small as the first level of menu
items -- means that silverlight has
to get out of the canvas to display
menu items ==> Is that even possible?
I know that this may sound ridiculous, but the project is to modernize the portal around sql server reporting services using silverlight in a sharepoint webpart. There's no possibility to change the setup, I just want to know if that could be achieved using silverlight. If it can't, we will fall back to superfish.
Thanks!
It is possible. Silverlight plugin should be set to windowless, so its content can overlap with html. Because Silverlight can not draw outside of its own surface you would have to make as large as biggest menu element or you could resize Silverlight container dynamically through javascript bridge.
Kinda new to Silverlight and have some experience with WPF but I'm doing a project with a group for a class making a game for WP7. I am currently in charge of the menu system for the game and I had a few ideas for "flashy" menu transitions. I got some going for the main menu but I wanted to do something cool for the options submenu.
Anyway my idea is to either fashion an expander or to have sort of a variation of a dialog box. But the way I envisioned it would be in either case the menu items blur but are still visible while the expanded menu is displayed or while the dialog is active. If I'm being confusing sorry :) but think of Windows 7 glass effect on the menu while other options are available.
What I'm getting at is I want to give this a shot but I have no idea how I would go about doing something like this. Could anyone point me in the right direction or outline some key steps for me to build off?
I tried finding something like this on Google but no such luck.
I would recommend taking a look at the many items available in the Education Catalog over on the AppHub - http://create.msdn.com/en-US/education/catalog/?contenttype=0&devarea=65&platform=54&sort=1
Been thinking about this for hours now. Im building a simple slideshow application, where the user creates slides through a web application and publishes them to a wpf "player". The user is allowed to create two types of slides one based on html and one based on xaml (thought this would be easy).
When i get the slide to the player i have to determine how to render/load the slide. The HTML slide i convert to xaml (code i found on msdn) as a flowdocument (but now what to do with it?). The Xaml i just get in "raw" xaml.
My plan is to convert both of these to xaml, then have the slide load the xaml in someway and display it, but how? And would this setup be the proper architecture? please bear in mind that this is a small player application.
Any help on either architecture or on how to display these are highly appreciated.
Sincerely,
Brian
Look at the Slide.Show project from Vertigo. It a WPF project released under codeplex. It may give you ideas on the design.
Why not just display them in the web page? There are a huge number of slideshow applications for the web already.