I have a page with a Pivot, with TextBox controls. In landscape, the SIP (the virtual keyboard) is opffsetted right by 42 pixels, thus clipped to its right.
Another app of mine also has a similar page, without the offsetted keyboard problem. Before I dig more into the differences between the two, has anyone ever encountered this problem before? Can we consider this a bug with Windows Phone 7.1?
(it does occur on a real device too)
It is a bug in windows phone:
If you set the Mode property on the app bar to Minimised and then turn the thing to landscape, the app bar pops back out. The code that figures out where to show the keyboard doesn't realise this and displays the keyboard as if the app bar is still minimised.
I solved it by changing the mode of the app bar as the orientation changes:
private void phoneApplicationPage_OrientationChanged(object sender, OrientationChangedEventArgs e)
{
if (e.Orientation == PageOrientation.LandscapeLeft || e.Orientation == PageOrientation.LandscapeRight)
{
this.ApplicationBar.Mode = Microsoft.Phone.Shell.ApplicationBarMode.Default;
}
else
{
this.ApplicationBar.Mode = Microsoft.Phone.Shell.ApplicationBarMode.Minimized;
}
}
This seems to solve the problem
Try checking if you have a set common right offset margin somewhere in your code. That is the most likely reason for this behavior.
I have never experienced this error myself.
Related
I am working on an old visual basic 6 app, which has just developed an issue, It never used to have.
It is an MDI form application, which has 1 main window which has a menu at the top and status bar at the bottom, along with 2 other status like bars. It also has around 50 Child windows to go within this master frame.
When the user maximizes any child window it seems the window maximizes but does not notice the toolbars at the bottom and it maximizes below them (out of view), so the bottom of the child window does not meet up with the top of the toolbars.
I have done 4 pictures which show it is design time, runtime normal and then maximized, as you can see it hides the buttons.
I have never seen this before
I have tried to code some resizing logic to counteract this in the child Private Sub Form_Resize() event, however, it has no effect at all.
Which leaves me to believe the window resizing when maximizing is dealt with via the windows system itself, or buried deep in vb, where I can not change it.
None of the controls have changed added/deleted on the forms, and I haven't changed any form/control values as far as I remember.
I have also tried bringing the controls to the front, then back etc, no impact
I have tried changing the zindex around in all ways, no impact
Has everyone ever seen this before or have any ideas
Thank You for reading, any help would be greatly appreciated
Thanks
normal working not maxed
maxxed screen showing issue
maxxed even with top menu closed
design time vb6
A pure VB6 solution for the child form:
Private Sub Form_Resize()
If WindowState <> vbMinimized then
Begin
If WindowState = vbMaximized then
WindowState = vbNormal
Top = Me.Parent.Top + Me.Parent.TopToolbar.Height
Height = Me.Parent.Height - Me.Parent.TopToolbar.Height - Me.Parent.BottomToolbar.Height
End
The trick is not to allow maximized mode, and resize the window to fit the remaining space.
The title bar is still at the top of the MDI window, unlike the default maximize behavior.
It has been well over 10 years since I used VB6, please excuse any code imperfections.
I don't have a solution (yet), but I've been facing the same problem with an app of mine. I believe that the issue is caused by the Win-7/Win-10 virtual desktop; the VB6 app thinks it's using the whole screen, but the task bar is on a separate virtual screen, which is on top. I'll post in this thread if I get it solved...
I need it so that when the Entry loses focus, the focus returns to the Entry (therefore locking the focus on an Entry).
I did the following code:
myEntry.Unfocused += (object sender, FocusEventArgs e) => {
if (!e.IsFocused)
{
((Entry)sender).Focus();
}
};
It works, but the keyboard stops working - I can't write anything.
Is this a bug? Can someone help me?
I found that this is a bug xamarin.forms 2.0.0.0. Updated and solved the problem.
I know on android if you click on an Entry and give it focus, the keyboard will appear, and then if you click another element, the Entry will lose focus and the keyboard will go away. So by refocussing on the Entry when it loses focus, you might be forcing the keyboard to be minimized. This is a total guess though.
What you might be able to do is set the most parent element's InputTransparent property to true and then only set the Entry.InputTransparent property to false so that the user is unable to click anything but the Entry.
If that does not work, then you could also try adding a transparent ContentView that covers everything except the Entry and set the ContentView.InputTransparent to true which would have the same effect.
Back in 2010, Pierre asked this question (his accepted answer doesn't work for me).
I'm having the same problem: I am able to successfully move the mouse around (and off!?!) the screen programmatically from my Cocoa Application, however bringing the mouse to the location of my dock doesn't show it (and some other applications aren't registering the mouse moved event, eg. games that remove the mouse)
The method I am using is thus:
void PostMouseEvent(CGMouseButton button, CGEventType type, const CGPoint point)
{
CGEventRef theEvent = CGEventCreateMouseEvent(NULL, type, point, button);
CGEventSetType(theEvent, type);
CGEventPost(kCGSessionEventTap, theEvent);
CFRelease(theEvent);
}
And then when I want to move the mouse I run:
PostMouseEvent(0, kCGEventMouseMoved, mouseLocation);
Note that this code DOES generate mouseover events for things such as links.
Now that's it's 2013, is it possible to fix this issue?
Thanks for your time!
I would both warp the cursor and generate the mouse-move event. I know from experience, for example, that warping the cursor, while it doesn't generate an event itself, modifies the subsequent mouse move event to include the moved distance in its mouse delta. I don't know if your synthesized move event will include the proper delta values on its own.
OK, so evidently MacOSX needs the mouse to be at exactly the edge of the screen for the dock to show!
Because I keep my dock on the left-side of the screen (due to many programs keeping vital buttons at the bottom of their windows), all I had to do was say
if (mouseLocation.x < 0)
{
mouseLocation.x = 0;
}
And it worked!
I am also using KenThomases' idea to warp the cursor as well.
(this answer is marked correct as it allows me to show the dock - however there are still some applications that are not responding to mouse input)
I am working on a DX11 game, and I want to clip the cursor during fullscreen mode to the fullscreen window. I use this method
void MyClass::_SetupCursor( BOOL bFullscreen ) {
// Clip cursor if requested
if( bFullscreen ) {
if(m_bShowCursorWhenFullscreen) {
ShowCursor(m_bShowCursorWhenFullscreen);
}
if(m_bClipCursorWhenFullscreen) {
// Confine cursor to full screen window
RECT windowRect;
GetWindowRect( m_hWnd, &windowRect );
ClipCursor( &windowRect );
}
}
else {
ShowCursor( TRUE );
ClipCursor( NULL );
}
}
However, when I am in fullscreen mode with 2 monitors, I can still move the mouse over to the other monitor. With resolution set to 2048x1152 in fullscreen mode, I get the window rectangle as 1360x768, and that is what it gets clipped to. I confirm that it is clipped using GetClippedRect.
So I have two questions:
1) Why isn't the mouse getting clipped to the monitor my window is in?
2) Why is the window rectangle measured as 1360x768 when I know for a fact the monitor is 2048x1152, and I have the resolution set to 2048x1152?
It turns out that for ClipCursor to work, you must have all your DX11 buffers and your window size correct. I found this out by running my application in fullscreen first, without toggling into it, and ClipCursor worked just fine, even with multiple monitors. For more information on when ClipCursor will fail, check out my other question on stackoverflow: Why is D3D10SDKLayers.dll loaded during my DX11 game? .
ClipCursor will fail ever time the situations i describe in that question arise. Also, in response to my 2nd question, the window size is incorrect because of the situation I describe in the linked question.
Unfortunately according to a comment on the documentation (by a user) it appears that this does not work for multimonitor setups. You may want to develop a method that will reposition the mouse when it goes off screen, turns off the rendring for it, then turn it back on when you move the cursor back to the window (to detect if the mouse moves off the window or not, there is windows messages for that).
I have problem with CPaneDialog.
I tested with SetPaneSize MFC feature pack sample projects. What is weird is that CPaneDialog can't be docked to MainFrm while CDockablePane can be. The CPaneDialog is also a child class of the CDockablePane, but it can't be.
Only DockToWindow( &other_CPaneDialog_instance... ) is possible.
If I call DockToPane(), the content of the CPaneDialog is not drawn or refreshed correctly.
How can a CPaneDialog be docked to MainFrm window?
Another problem is about drawing. If remove codes for tree control in the SetPaneSize sample, the content of the view1 ( an instance of CDockablePane) is not redrawn properly.
After doing some experiment, I decided that something should be done in its OnSize and OnPaint method. (OnSize is more critical. ) Is this expected behaviour?
While converting an older MFC-application I ran into similar problems with the feature pack. I didn't have the time to solve it correctly, but I used following workaround:
take your dialog resource and put it in a CDialogBar class.
now derive a class from CDockablePane
in the OnCreate-method of the pane, create your dialogbar.
2 more things:
void CInputPane::OnSize(UINT nType, int cx, int cy)
{
CDockablePane::OnSize(nType, cx, cy);
m_pInputBar->SetWindowPos(NULL,0,0,cx,cy,SWP_NOACTIVATE | SWP_NOZORDER);
}
BOOL CInputPane::OnBeforeFloat(CRect& /*rectFloat*/,AFX_DOCK_METHOD /*dockMethod*/)
{
return FALSE;
}
This assures proper sizing of the dialog and preventing the user from dragging the bar around.
HTH, it worked for me.
Converting HexEdit to MFC9 (see http://www.hexedit.com) I ran into this problem. I tested in VS2010 (MFC10) and this bug appears to have been fixed.
Also note that this problem is not a major thing as you can just use DockToWindow in CMainFrame::OnCreate to dock to a CDockablePane (if you have one). The user can float the window or dock it elsewhere and the position will be remembered and restored when the program is re-opened.
I am pretty sure someone new about this bug in MFC9 - hence the obvious workaround in the SetPaneSize demo (calling CDockablePane::DockToWindow rather than DockPane as was used for all the other dockable windows). But at least it is fixed in MFC10.
Another bug I found is that if a CPaneDialog is floating when closed (hidden), then when you restart the application the pane is reopened, rather than being restored in the correct (hidden) state. This does not occur if the pane is docked when closed. This has also been fixed in MFC10.