After navigation using goto() function in Sapper the scroll top position sets back to zero. Is there an easy way to control this. Specially when using replaceState: true. Its a bit odd that scroll top sets back to zero with replaceState: true option.
Edit: Also input fields also lose focus after goto(/url, {replaceState: true}). I feel this behavior is odd. With replaceState: true option. goto() should preserve these (scroll poisition.. input focus.. etc.) or Maybe..
Edit-2: This is also the behavior of history.replaceState(). Is doesn't lose scroll position and input field focus.
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
If I have an NSTextView which is in this state:
How can I tell the textview that if a user presses shift+right, that rather than extending right towards the 'o', it instead de-selects the 'e'? I though this had to do with the affinity, but I have tried setting it to both NSSelectionAffinityUpstream and NSSelectionAffinityDownstream via the following code:
[self setSelectionRange: NSMakeRange(9,6)
affinity: x
stillSelecting: NO];
But that made no different. Hitting shift+right still selected the 'o'.
NSTextView knows how to do this SOMEHOW, because if you cursor position between 'w' and 'o', then hit shift+left until it matches the screenshot, then hit shift+right, it matches the behaviour I mentioned.
I'm ok to override the shift+arrow code and roll my own, but I would rather allow NSTextView to do its own thing. Anyone know if I am missing anything?
I'm not sure what you're trying to do, since this is the default text movement/selection modification behavior. Are you trying to override this to always do this one thing or are you trying to add another keyboard shortcut that overrides this behavior? In either case, some background:
Selection affinity doesn't quite work the way it sounds (this is a surprise to me after researching it just now). In fact there seems to be a disconnect between the affinity and the inherited NSResponder actions corresponding to movement and selection modification. I'll get to that in a moment.
What you want to look at are the responder actions like -moveBackwardAndModifySelection:, -moveWordBackwardAndModifySelection:, and so on. Per the documentation, the first call to such selection-modifying movement actions determines the "end" of the selection that will be modified with subsequent calls to modify selection in either direction. This means that if your first action was to select forward (-moveForwardAndModifySelection:), the "forward end" (right end in left-to-right languages; left end in right-to-left, automagically) is what will be modified from that point forward, whether you call -moveForward... or -moveBackward....
I discovered the disconnect between affinity and -move...AndModifySelection: by looking at the open source Cocoatron version of NSTextView. It appears the internal _affinity property isn't consulted in any of the move-and-select methods. It determines whether the selection range change should be "upstream" or "downstream" based on _selectionOrigin, a private property that is set when the selection ranges are modified (via the -setSelectedRange(s)... method or a mouse down / drag). I think the affinity property is just there for you to consult. Overriding it to always return one value or another doesn't change any behavior, it just misreports to outsiders. The _selectionOrigin seems only to be modified via -setSelectedRanges... method if the selection is zero-length (ie, just cursor placement).
So, with all this in mind, you might have to add one step to your manual selection modification: First set an empty selection with a location where you'd like the selection origin to be (forward end if you want backward affinity; backward end if you want forward affinity), then set a non-zero-length selection with the desired affinity.
Roundabout and ridiculous, I know, but I think that's how it has to be, given the CocoaTron source code.
I am using a ZedGraphControl in a WindowsForms project in C#. The ZedGraphControl is V5.1.5.
The data in the control is static and I add it all before the form is shown. The X axis of the data consists of numbers indicating seconds offset from the beginning. in other words from 0 to some number of seconds.
I want to initially show the last 5 seconds, but provide a horizontal scrollbar so the user can scroll back and forth. I set the "graphPane.XAxis.Scale.Max = maxX;" where maxX is the largest X value in my data. I set the "graphPane.XAxis.Scale.Min = maxX - 5;".
The data starts off displaying the way I want it, but when the user scrolls the horizontal bar, bizzar behavior occurs.
As you drag the thumb of the scrollbar to the left, the beginning of the data shown in the grid moves to the lower values as expected, and the thumb of the scrollbar moves to the left, but the right edge of the thumb stays at the right of the scrollbar and you cannot move back to the right. It is as if the data to the right of the viewing range gets truncated as you scroll left.
I cannot find any reason for this nor any way to control it. Does anyone have any ideas about this behavior?
Ok, found it myself.
I found a fine article that describes scrolling:
Add a ScrollBar
In it the author specifically says "the scrolling will be wacky because the scrollable range has not been set".
I used the sample "Manually Setting the Scroll Range" and the part that I was missing is setting the zedGraphControl1.ScrollMinX and zedGraphControl1.ScrollMaxX properties. Once I defined these values everything started working as expected. I also found that in my case, the value of zedGraphControl1.IsAutoScrollRange had no effect, but I left it set to false to be consistent with the example. This would probably have an effect if the dataset is dynamic.
I have implemented a slickgrid and activated keyboard navigation.
When the users is scrolling down using the down-arrow key and reaches the last of the currently visible rows, the grid loads a whole new section of rows and places the selection at the top.
My user tests have all included a complaint about this behaviour as they all find the jump jarring.
I would like to implement behaviour, so the grid scrolls just one line at a time, when I press the down arrow while the last visible row is selected.
I was wondering if there might be some setting, I have overlooked, or if anyone has some suggestions for how to approach the task of adding this behaviour.
(the "problem" is the same, when you scroll upwards - only reversed of course)
This is controlled by the doPaging argument in scrollRowIntoView(row, doPaging) (https://github.com/mleibman/SlickGrid/blob/master/slick.grid.js#L2662). There's no setting to control that behavior, but you could easily add one.
It was initially written this way to make keyboard navigation faster since continuously navigating down doesn't have to do as much work as it would have if we were updating the grid on every 'row down'.
I am building an InDesign panel with ExtendScript which finds text and shows it to the user. To do this, I use the showText() method of the Character object. The problem is that sometimes the text I'm looking for doesn't appear because, even though the method does show the right page at the right place, the text has overflown and is not visible.
Is there a way to check if the text is visible or not? Ideally, I would like to be able to fall back on the story editor if the text cannot be seen as-is...
To check the situation for an individual character, see the parentTextFrames property, it returns an array with 0 or 1 frames. In rare cases of insertion points whose left side is in one frame while the right side is in the following, you get two frames.
app.selection[0].characters.item(0).parentTextFrames.length
You can also compare the index of your character against the last index in the last text container of the story, e.g.
app.selection[0].parentStory.textContainers.pop().characters.lastItem().index
Of course you should first see whether there is overflow at all ...
app.selection[0].parentStory.overflows
You may call the baseline property for the text in a try/catch statement. If text is visible, baseline will return a value, otherwise it will raise an error.
Loic