Has anyone seen an implementation or plugin for extjs where you can "pull off" or "dock" tabs/windows the way you can with a browser? Is it even possible?
Searching has not revealed much but I did come across a proposed solution in an older version:
http://www.sencha.com/forum/showthread.php?16842-Dockable-floatable-panels-in-ExtJS
#DmitryB
To clarify, in chrome if I have multiple tabs in the same window like so:
And I "drag" one of the tabs, it pops off into a new window:
I imagine you might accomplish this by moving the content of the tab panel into a window but not sure how to go about it.
In a nutshell:
- Make the tabs draggable, watch for the drag event and mark the
tab-strip as your "safe" zone
- When a tab is dragged and then "dropped" (as in, the drag event ends) you do a check:
> Is the tab within the safe area?
No: Create a new Ext.Window at the x/y of the mouse, copy the components/HTML
out of the original panel and insert them into the new window. Destroy the
original panel.
Yes: Do nothing.
Unfortunately, I am still quite jaded from learning D&D in ExtJS3, so I can't offer any help with this and real code pertaining to ExtJS 4, however the concept seems relatively straightforward to me. I would say you're going to probably want to do your best to NOT have this be flashy - unless you REALLY REALLY need to, I wouldn't worry about showing the panel's contents while you drag the tab - much less show the panel itself. Just let the tab element get dragged around the screen and copy when it's released outside of the safe zone.
Related
Hoping you can help me as I have searched a lot of forums and did not find the same question, never mind the answer I need :)
I have a power point pack which I have put together. It is built to be a template for my team to use repeatedly and is set up using slide masters to control the layout. Each layout slide in the slide master includes two checkboxes to identify either a pass or a fail. My problem is that when you insert a new slide (by either duplicating an existing slide or adding a slide from the slide master layout), and change the checkbox value it also changes on the other slide. Is there a way either using some quick VBA or otherwise to stop this from happening and break the link between the two slides.
Any help would be really appreciated.
In a weird way, this is reasonable behavior from PowerPoint, though it certainly does seem bizarre.
Shapes on a master layout appear on any slide based on that layout. Though they appear on the slide, they're not editable on the slide; it's as though the slide were a clear layer above the layout, one that you can add more stuff to but that you can't "penetrate" to get at the stuff on the layout below.
Placeholders are a special case and so, apparently, are ActiveX controls like your checkboxes, which DO allow editing. So what's happening is that when you change a text box, you're changing the text box on the layout, not on the slide itself (the checkbox doesn't even exist on the slide ... you can't select and move it in normal view, for example, unless you go to the layout in Master view).
When you change the checkbox, you're changing the one on the layout, and since the checkboxes appear on any slide based on the layout, when you change the checkbox, you're changing the one on the layout, ALL of the slides based on that layout get the changed checkboxes.
Some mildly tricky VBA could look at each slide and if it's based on the layout that contains the checkboxes, COPY them to the current slide from the layout and finally make the checkboxes on the layout invisible.
The simpler solution might be to supply a sample slide with the checkboxes ON the slide and let the users copy/paste it into their presentations.
[later]
I've reported this to MS as not so much a bug as a design oversight; the behavior may make sense, but it's not useful and can mislead users (as you well know).
I'd suggest that you visit https://powerpoint.uservoice.com and suggest that ActiveX objects on masters/layouts behave more like placeholders ... spawn new instances of themselves when a new slide based on the layout is added rather than letting the user THINK that's what's happened.
I've got a pretty complex question for any Maya coders...
I want to utilize a drop down menu similar to that of the cmdScrollFieldExecuter's [script editor's] "Show Tooltip Help". It looks like a window that has been appended to the bottom of the inputted text with a feedback of all relative commands or strings.
Does anyone have experience with appending a similar textbox/ window/ menu to typed input, and if so, can you toss me in the right direction?
Note: I am not talking about "optionMenu".
Alternatively, is there a way to get cmdScrollFieldExecuter to reference a different array or set of strings?
A complete port of that won't be possible in vanilla Maya - You'd need to use python and QT because the built-in GUI objects (such as TextField) don't fire any events on keypresses so you won't be able to live-update as the user types.
You can almost fake the visual appearance with a window whose title bar is set to off. Use a formLayout to dock a TextScrollField inside it. You'll need to hack up some way of dismissing it since it won't have a close box -- you could put it on a timer or add an invisible button covering the whole thing which closed the window when clicked
I have several Wpf pages in my project, these pages have different forms and ui control indide theme. The image below shows the mainWindow and there are two button.
I want to show a specific page when I click on + or Edit button using the Frame control which is highlighted.
apparenatly this woks:
Page1 me = new Page1();
mainFrame.Content = me;
But it has an IE navigation sound and a toolbar appears after going to page2.
any better way to show diffrent pages and not using a frame?
You may want to convert the Page into a UserControl. You can then put that control inside some other container, such as a Grid. You'll have to manually swap out the pages in the container when navigating, but it looks like you're doing that anyway.
The purpose of the Frame control is to allow navigation. If you don't want navigation, then don't use Frame. You can turn off the navigation toolbar, but that won't actually disable navigation - there are mouse buttons and keyboard shortcuts for navigating back.
If you just want to host a UI element without navigation, use something simpler, like a Border element - put the content in its Child property. You can change the Child as many times as you like at runtime.
I was able to set the frame control's NavigationUIVisibility to Hidden. This solved the problem for me. I am using Visual Studio 2010 though so it might not be applicable to older VS versions.
Ian Griffiths, what you suggest increases the workload on the developer substantially. And you are stepping outside of the underlying paradigm of XAML.
In my case I'm developing a game application and have chosen WPF as the UI platform as much as possible. For me that means a intro screen, character select, etc. The purpose of Pages is to encapsulate the navigational need of such an application.
I suspect your downvote is due to your statement "If you don't want navigation...". Upon re-reading the original posters question I see he does want navigation, he just wants it on his own terms. I would have voted you down too. YotaXP's solution neglects the issues with using a User Control, particularly if it may contain other User Controls. It looks like Chris Calvert came up with an actual solution to the poster's issue within the parameters of the problem.
I would be curios if I could override the navigation hotkeys and such within the existing paragimn but that's properly in its own thread.
I'm trying to save and restore the position of the document within a FlowDocumentReader to create a bookmark feature. There doesn't appear to be any seeking or search feature build in that is publicly accessible, leaving me with the following options:
Use FlowDocumentPageViewer instead,
saving the page each time the window
is resized and restoring it as soon
as the app is reloaded.
Loop through all the elements in the
Document property of
FlowDocumentReader, looking for the
first one that passes an on-screen
hit test, then using reflection to
use the internal search features to
bring that text back into view at a
later time.
Serialize the entire control.
Write my own document viewer control.
No. 1 is annoying because I'd have to forfeit the two-page and scroll viewing options of FlowDocumentReader. It also means seeking to the saved page before the user has a chance to resize the window. This is fragile and would probably break if the user say, switched resolutions between sessions.
No. 2 is a garish hack that would probably work, but be slow and break completely if the internals ever change.
No. 3 is looking like my best bet, but it only lets me save/restore the current position, not set arbitrary bookmarks.
No. 4 is just too much work. These controls are utterly fantastic, I just need this one feature...
Is there any other way to go about this?
This seems to work well for page views, but not for scroll view, which is okay.
reader is of type FlowDocumentReader, and document is the FlowDocument within it.
Set the bookmark:
var paginator = ((IDocumentPaginatorSource)document).DocumentPaginator as DynamicDocumentPaginator;
var position = paginator.GetPagePosition(paginator.GetPage(reader.PageNumber - 1)) as TextPointer;
bookmark = position.Paragraph;
Restore the bookmark:
bookmark.BringIntoView();
Is there a simple way to tell what triggered Click event of a Button apart from setting multiple flags in Mouse/Key Up/Down event handlers? I'm currently only interested in distinguishing mouse from everything else, but it would be nice to handle Stylus and other input types if possible. Do I have to create my own button control to achieve this?
Edit: To clarify why I care: in this particular case I'm trying to implement "next" and "previous" buttons for a sort of picture viewer. Pictures in question may be of different size and buttons' positions will change (so they are always centered below picture). It's quite annoying to follow such buttons with mouse if you need to scroll through several pictures, so I want to keep mouse position constant relative to clicked button, but only if it was clicked by mouse, not keyboard.
Edit2: It does not matter whether the buttons are on top or down at the bottom, since the center can change anyway. "Picture viewer" here is just an abstraction and in this particular case it's important for me that top left corner of the picture retains it's position, but it's out of the scope of the question to go in details. Scaling the picture is not so trivial in this sort of application as well, so I do want to know the answer to the question I asked not going into UI implementation discussion.
if (InputManager.Current.MostRecentInputDevice is KeyboardDevice)
You should instead handle specifically the MouseXXX, StylusXXx, and KeyboardXXX events.
Could you elaborate on why you would care?
Having written many custom controls myself over the years, I cannot recall one instance where I cared how a click event was triggered. (Except for that pre VB6 control lifecycle glitch that fired the got focus-click-lost focus in a different order depending on whether you clicked a button, used an accelerator key, or pressed ENTER as the default).
Personally I find it annoying when people place buttons at the bottom of Windows forms and web pages. Read some of the literature on UI and you will find that most people don't even get that far if they don't find something interesting on the page/form. I like to be able to click next as soon as I know the content is of no interest to me, so keep the nav buttons prominent at the top.
I would put the prev/next at the top of the picture where you can control their position. Dancing those buttons around goes against most opinions on UI consistency. Further creating a different experience for a mouse user versus a keyboard user also goes against most current wisdom on good UI design.
The alternative is to choose a constant max size a picture can obtain on the UI and if it exceeds that scale to fit, otherwise allow it to change freely within a frame. This keeps your buttons at the same place if you absolutely must have them on the bottom.
You could create an enumeration with the different devices, have a global property that you set every time the mouse/keyboard/etc. is initiated, and just refer to this when needed.