How to prevent scrollbar re-positioning on update=#form? - jsf

I have a long form, and the client have to scroll vertically the screen to see all fields.
But, every time one of those components with the property update=#form is fired, the screen get back to the top position.
So, the question is:
There is a way to keep the scroll bar in the same position after an update=#form ?
Important: The scroll bar back to the top only in the first update=#form, after that, the screen keeps the current position.
I am not sure if it's a bug or I am doing something wrong that is causing that behavior.
And yes, i really have to update the whole form
e.g.
<p:commandButton id="btnVerifyLogin" update="#form" value="Verify"
actionListener="#{demandController.VerifyLogin()} />

I had this issue before, where I had to update the whole form.
What I have learned that when I update the form containing the button that has been pressed (like your Verify button), the browser somehow loses the focus on that button and just scroll back to the top.
I came up with a workaround.
<p:commandButton id="btnVerifyLogin"
update="#(form :not(#formId\\:btnVerifyLogin))"
value="Verify"
actionListener="#{demandController.VerifyLogin()} />
Basically I update the form but not the button, this way the browser keeps the scroll as it is.
Others would suggest that onstart we can call var scroll = $(window).scrollTop(); in order to preserve our scroll position, and oncomplete we call $("html").scrollTop(scroll);, but this won't work since the oncomplete won't be triggered since the button is updated inside the form!
Again this will work only with Primefaces 4, and recently I avoid updating full forms, I prefer to use selectors.
Hope this helps.

Related

WinRT XAML - how to fix higlight issues?

When I'm testing my app on a mouse-driven device, I'm seeing a couple of odd highlight issues that I would like to try and resolve.
The first occurs when I call up the app bar, hover the mouse over a button (at which point the button goes grey) and then press Escape to dismiss the app bar. If I then call up the app bar again, the button has stayed grey, even if the mouse isn't over it, and remains in that state until I move the mouse over it and then away again.
I can't immediately see a property of the button that I can reset to clear that state when the app bar gets dismissed.
The other oddity I'm seeing is that sometimes the first item in the list on the page will get a box drawn around it:
This seems to happen when the app bar is being dismissed. I'm guessing that this is because the item is in a particular state that causes the box to appear but I'm not sure what state or how to clear it. The box does not appear during normal use of my app.
Thanks for any clarification or solutions you can provide.
I found a simple way to workaround this issue. In the code for Clicked/Tapped set Visibility of the button:
CreateNewDatabase.Visibility = Visibility.Collapsed;
CreateNewDatabase.Visibility = Visibility.Visible;
It will reset button state to Normal.
Hope this helps!
So, the issue is that the VisualState for the Button is being set to PointedOver, and then not being unset (because your mouse isn't leaving the bounds of the control and therefore triggering a PointerExited event). What this means is that you'll have to manually set the VisualState of the Button if you want it to change in this manner. You could do it on AppBar's Closed event. Basically, do a recursive check of all Children of the Content property of the AppBar using the VisualTreeHelper. Check to see if the Child is a Button. If it is, set its VisualState using VisualStateManager.GoToState().
I've also figured out what was causing the black box around the button - it is to indicate that the button has Focus.
The rather strange thing is that I'm not really sure why that specific button is getting focus or how a user is supposed to give focus to a button without it just randomly happening so, until I figure that out, I've decided to comment out the Focus state support from the Visual Manager XAML used in the default GridView item style.

Disable a commandButton from receiving the "Enter" key

In the form I am creating, I have lots of buttons that depending on the data state, are disabled or enabled.
I have an issue where, in certain situations, my "Reset Form" button is the only enabled button left on the screen, so it accepts the "enter" keypress... and blows away all the user information.
I need to retain usage of the enter key with the other fields, but I'd like to hide this reset button from ever being seen on the page DOM as the "firstnext" button to invoke on enter keypress.
I've seen a few solutions w/ javascript, but I was hoping there was a native JSF way to do this, or even with an extension library. Taborder was of no help... Best I could come up with that works is a hidden button on the page dom in front of the reset button that dev/null's. There's gotta be some sort of cleaner solution.
Thanks in advance.
Turns out, if you declare a button as type="reset" it prevents firstnext recognition. You can still have an action="#{bean.resetFields}" method being called and it will give you the best of both worlds.

Change "back" NavigationItem text in Monotouch?

Is it possible to change the "Back" button text in a NavigationItem? At present, the caption of the back button assumes the title of the previous layer in the navigation stack, which is expected.
However, the NavigationItem's LeftBarButtonItem can be changed using code such as this:
UIBarButtonItem backButton = new UIBarButtonItem("Back", UIBarButtonItemStyle.Plain, null);
myNewView.NavigationItem.SetLeftBarButtonItem(backButton, true);
This works and the back button is displayed as expected, but the button is a square and does not navigate back to the previous layer as expected. I'm guessing that the correct event needs to be assigned to it, but I have no idea what it should be.
How would one go about ensuring that the new UIBarButtonItem has the correct event and arrow shape?
Note: I have also tried re-using the `LeftBarButtonItem' as suggested in this SO question, but I still don't know how to customize the button caption. I am probably just missing the obvious.
Thanks!
Set the title on the previous viewcontrollers navigationitem. I answered this before and will look up the link.
Ah, yes: Separate title in NavigationBar and navigation buttons

Problems with refreshing a draggable MFC window

Greetings.
I have to make a draggable MFC dialog window, which has a background - used that: http://www.codeproject.com/KB/graphics/picturewindow.aspx - and has several picturebox controls. I have tried two approaches, and while they do work, they have some problems.
First approach is "Manual" - on the LBUTTONDOWN message I check if it;s on a clean area of my window, and set a flag variable. On MOUSEMOVE, the flag is checked and if it's set, a MoveWindow function is called, and then, Invalidate(1). On LBUTTONUP, flag is unset.
This approach works correctly and redraws as needed, but is somehow very slow - if I'm moving the cursor too fast, the window falls behing and isn't dragged, as cursor's not over the window anymore.
The second approach is "Automatic" - I just call
DefWindowProc(WM_SYSCOMMAND, SC_MOVE+2,MAKELPARAM(point.x,point.y));
on LBUTTONDOWN, and it handles the rest, it's quick and never fall behind, but when I drag it over screen's edge ( so that some part of the window gets invisible), when I drag it back, all the controls get invisible and are not refreshed, background is okay. I suppose that's because Invalidate() isn't called during movement that way, as I actually call it after calling DefWindowProc() and so, everything is refreshed properly when I depress the button.
What should I do to improve either of those solutions? I need it both fast and correct. I may have not provided some required information, I'll add it is need arise.
Thanks in advance.
Solved the problem, by modifying the second way. I added a total redraw to the OnPaint(), and to get rid of flicker, I only redraw durng dragging, by using a flag variable.

Altering the YUI menu's mousing behavior

I'm using Yui to build a "popup" menu that works a bit differently with the mouse than usual. This is not a ContextMenu, because I want it to respond to left clicks, and the ContextMenu seems bent on responding to right clicks.
Following the examples, if I do this, the menu comes up and everything is close to how I want it:
YAHOO.util.Event.addListener(myClickTarget, 'click', myThingGotClicked);
In my myThingGotClicked function, I manually set the menu's position and show() it.
My problem is that I want to "bind" the menu visibility to the state of the mouse button. That is, on a mouseDown, I want the menu to come up, and on a mouseUp, I want the menu to disappear (selecting the active item, if any). So, listening to the 'click' event doesn't do the right thing, because a "click" is only sent after mouseUp.
The "obvious" solution is to do this:
YAHOO.util.Event.addListener(myClickTarget, 'mousedown', myThingGotClicked);
But this doesn't work. Stepping through in a debugger, you can see that it does actually bring up the menu on a mousedown, but then something immediately hides the menu. At full speed, it looks like nothing happens at all.
Any thoughts?
The problem is that the MenuManager class listens for the mousedown event at the document level and hides all visible Menu instances. So, since you are building a unique sort of Menu implementation, you'll need to stop the propagation of the mousedown event inside your handler so that the MenuManager doesn't handle the event. Here is some pseudo code for you:
var myThingGotClicked = function (event) {
YAHOO.util.Event.stopPropagation(event);
// Do other stuff
};
YAHOO.util.Event.on(myClickTarget, 'mousedown', myThingGotClicked);
Todd
That's a bit closer, as the menu does pop up, but if you try to make a selection in the menu, the text selection of the page underneath goes sort of nuts. I also need to add a mouseup handler, I think, as the menu doesn't go down on mouse release.
What I really want here are menus that work like menus on every version of the Mac OS (until more recently when OS X added the "click to make the menu 'sticky' to the default behavior).

Resources