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.
Related
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 trying to build an app in winforms with something similiar to masterpages in asp.net - a menu on top and when choosing an option from the menu the entire screen on the bottom will change while the menu remains (there are 10-15 screens in the future app, some are quite similar, some are not).
What is the best way of doing this? Should I use different forms for each screen or use a panel or something else?
If I use a panel or something how do I manage to use the designer with so many panels taking space on the screen?
Try with the MDIParent Form's. View the Example
http://www.codeproject.com/Articles/12514/Multi-Document-Interface-MDI-tab-page-browsing-wit
If it is just keeping the same menu and opening/closing parts of the UI you could simply add and remove instances of usercontrols to the main form.
If you need more features such as docking (like Visual Studio) look at this
Another option is to use Form inheritance
Which one to select depends on what you want to reuse and the features you need.
One option would be to make your application an MDI window and then load entire forms, maximized, into the parent window.
Then, you would be able to treat each form as its own self-contained item, since it really would be exactly that.
Is it not an option for you to use WPF? A WPF browser application fits the paradigm you are describing quite well.
I need a WPF control that acts like the Panorama control for Windows Phone 7, but I need it for a desktop application.
It will contain a series of panels (or Panorama Items) that the application will be able to slide through horizontally programmatically.
Also, the content inside the panels not currently displayed on the screen will need to be "lazy loaded". In other words, they should be referenced but not loaded or rendered.
Can I somehow adapt the WP7 Panorama control to do this? Or will I have to develop a custom control from scratch to behave similarly to it?
Thank you!
EDIT:
I could probably use a VirtualizingPanel to implement the lazyload behaviour.
MahApps.Metro while still not super mature does allow for the wp7 Panorama control. Demo of how to use a panorama here. I've played with it a little and while its not the most customizable thing out there it gets the job done. Pretty sweet. Also Sacha Barber (Codeproject Demigod) wrote up an article on making your own. Of which I haven't looked at yet but, the guy usually does awesome work. So I'd check that one out as well.
http://blogs.microsoft.co.il/blogs/arielbh/archive/2010/10/21/porting-windows-phone-7-s-panorama-control-to-silverlight-4.aspx gives some clues about how do to this.
It suggests using http://phone.codeplex.com/ as your base and then you can use http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=4b281bde-9b01-4890-b3d4-b3b45ca2c2e4 (Microsoft Surface Manipulations and Inertia Sample for Microsoft Silverlight) to run convert get it to respond to touch.
Seems none exist as far as I can see so far.
This blog has started an attempt at making it, so you could work from there to make your own. Be sure to also check out this page which details the creation of an individual panorama item too.
Is it possible to drag an HTML 5 object, e.g. an <a draggable="true">, into a Silverlight 4 control and accept it? We've attempted to build a simple prototype using an HTML 5 example and a trivial Silverlight control but the cursor changes to the no-entry sign whenever we hover over the Silverlight control. We do, however, get drag entry events firing in Silverlight.
Our control happily accepts files dragged from the desktop as expected. We think we've got the HTML 5 drag events set up correctly, and I can possibly get our test published somewhere in case that will help. We've successfully implemented dragging inside a Silverlight control but we now need to integrate with non-Silverlight page components.
Is this actually possible to set up or are we just doing something wrong? Thanks for any advice!
Silverlight Drag drop from external sources currently supports only file lists.
You may however be able to get the <object> tag hosting the Silverlight plugin to respond to a dragging. If so you can use the Silveright HTML Bridge to handle these DOM events. Its a bit of a long shot though.
Short answer, as Anthony says is No.
You can emulate the functionality by using the
the drag entry event and mouse button up event, then create a silverlight control that most closely matches the HTML one you were dragging, and hide the original html control (which should snap back to its original position)...
Its a little messy, but it works...
Incidently, as far as i'm aware, dragging between 2 silverlight instances on the same page would require a similar technique...
I am working on a little WinForm app and have been trying to find the answers to a few questions i have without any luck. Im a ASP.NET developer so WinForms development is new to me.
Here is my main question:
How do I create a menu system that once selected the contents will render in the Main form of the selected item. If its a GridView I want to the GridView to render inside the main application so they can navigate away without having to deal with the modal popup. I do not want to popup forms unless i explicitly say so. I guess the equivalent to this would be using a Master page in ASP.NET.
Make sense?
The closest thing to Master pages in winforms would be MDI (multiple document interface), which is a hideous Windows 3.1-era abortion of a user interface. Why this option is even still around, and why anyone still uses it, is beyond me.
The second closest thing (and something more acceptable as a UI) is just to have one main form in your application, and implement the different pieces of functionality your app requires as separate user controls which are displayed on the form and hidden as the context requires.
A weirder method, but one that might also work for you, is to use forms inheritance - design one "master" form with the menus and controls that you want to always be present, and then have each form in your app inherit from that master form. This would not appear to the user to be much different from my second option above, so I wouldn't bother with it.
There really isn't anything similar to Master pages in WinForms.
The closest to what you want to use would be a TabControl selecting a different tab will display that tab over the other tabs. If you don't like the tab look you could extend the TabControl to not show the tabs or hack it together by placing the TabControl inside a panel just large enough to show the content but not the Tabs and change tabs programatically in your menu control.