Note that there are some explanatory texts on larger screens.

plurals
  1. POWindows Mobile 6.1 - Resizing HTMLControl's Window on Soft Keyboard Show/Hide
    primarykey
    data
    text
    <p>So this is a common problem and has been addressed in a few places - not specific for an HTML Control on Windows Mobile 6.1 professional though. </p> <p>So here's my problem</p> <ul> <li>A <code>WC_HTML</code> HTML Control created as a child window of a Windows Mobile application window. </li> <li>HTML Control serves html pages with editable fields.</li> <li>When the full page is full of editable fields and the user is using the soft keyboard, for the fields at the bottom of the page, the soft keyboard overlays a few fields. </li> </ul> <p>What I definitely missed out was to resize the window based on soft keyboard open/hide events. </p> <p>What I tried already</p> <ul> <li><p><strong>First Approach</strong> - Using globally declared <code>SHACTIVATEINFO sai;</code> object which is initialized before the parent container window is created which is then passed onto the WM_SETTINGCHANGE AND WM_ACTIVATE methods of WndProc (as explained <a href="http://msdn.microsoft.com/en-us/library/ms911981.aspx" rel="nofollow">here</a>). This doesn't have the desired effect. I have tried both - passing the parent HWND (as recommended) and also the Web Control's HWND - nothing happens.</p> <p><code>case WM_ACTIVATE: SHHandleWMActivate(hWnd, wParam, lParam, &amp;sai, 0); break;</code> </p> <p><code>case WM_SETTINGCHANGE: SHHandleWMSettingChange(hWnd, wParam, lParam, &amp;sai); break;</code></p></li> <li><p><strong>Second Approach</strong> - Also tried manually resizing the window based on the keyboard event by checking the event using <code>SIPINFO si;</code> and then using <code>si.fdwFlags</code> to determine if the soft keyboard is being hidden or not</p> <pre><code>case WM_SETTINGCHANGE: { SIPINFO si; switch( wParam ) { case SPI_SETSIPINFO: { memset( &amp;si, 0, sizeof( si ) ); si.cbSize = sizeof( si ); if( SHSipInfo( SPI_GETSIPINFO, 0, &amp;si, 0 ) ) { RECT rcMenuBar; // Get the size of the menu bar GetWindowRect(g_hWndMenuBar, &amp;rcMenuBar); // Keyboard opens up if(si.fdwFlags == 0x00000003) { MoveWindow(webControlHWND, 0, 0, (si.rcVisibleDesktop.right - si.rcVisibleDesktop.left), (si.rcVisibleDesktop.bottom - si.rcVisibleDesktop.top), TRUE); } else if(si.fdwFlags == SIPF_DOCKED) { // keyboard closes down - weird that this msg comes when keyboard is closed instead of SIPF_OFF // visible area above menu bar si.rcVisibleDesktop.bottom -= (rcMenuBar.bottom - rcMenuBar.top); MoveWindow(webControlHWND, 0, 0, (si.rcVisibleDesktop.right - si.rcVisibleDesktop.left), (si.rcVisibleDesktop.bottom - si.rcVisibleDesktop.top), TRUE); } } break; } } break; } </code></pre></li> </ul> <p>This second approach causes weird un-explainable problems - Here's what i observed</p> <ol> <li><p>If i sent one of the editable fields to focus using the JS, the Windows mobile's SETTINGCHANGED is triggered for <code>(si.fdwFlags == 0x00000003)</code> for which the <code>MoveWindow()</code> call is made to resize the window to the smaller visible area (after the keyboard comes up), And there is another message triggered (happening automatically) - could be because of the <code>MoveWindow()</code> and the Soft keyboard closes down and the window is resized to the full screen. After debugging I see that when a soft keyboard is opened, the message received is first <code>0x00000003</code> and then next <code>0x00000002 (SIPF_DOCKED)</code> for closing.</p></li> <li><p>After #1 happens, sometimes the field is not clickable from the touch screen (can't focus on the field) but one can navigate to the field using the Direction pad or the soft keyboard arrow keys. So this is a big problem being caused due to Issue#1 where the keyboard is highlighted and then automatically hidden. Although i am able to pull up the Soft keyboard by force using the button (the auto toggle feature seems to be lost because of the change). </p></li> </ol> <p>Has some one faced this problem before? I am hoping every one who has used the HTMLControl for Windows Mobile 6.1 professional must have gone through the same issue. </p> <p><strong>UPDATE - 22Mar2011-11:27AM</strong> Here, my parent window doesn't handle the WM_SETFOCUS or WM_KILLFOCUS methods, instead the child HTML Control (WC_HTML) would probably handle them. The worry here is that the Parent Window HWND's messaging loop gets the WM_SETTINGSCHANGE message which needs to be translated to the child window. I've also tried to do exactly like the HandleSIP Windows Mobile SDK sample which does by having the <code>SHACTIVATEINFO</code> object <code>memset()</code> each time a message is received - unlike previously where it was stored globally and the <code>memset()</code> is done once before the window is created or in <code>WM_CREATE</code></p> <pre><code>case WM_CREATE : { memset(&amp;sai, 0, sizeof(SHACTIVATEINFO)); break; } case WM_ACTIVATE: if (SPI_SETSIPINFO == wParam){ memset(&amp;sai, 0, sizeof(SHACTIVATEINFO)); SHHandleWMActivate(webControlHWND, wParam, lParam, &amp;sai, 0); } break; case WM_SETTINGCHANGE: { if (SPI_SETSIPINFO == wParam){ memset(&amp;sai, 0, sizeof(SHACTIVATEINFO)); SHHandleWMSettingChange(webControlHWND, wParam, lParam, &amp;sai); } break; } </code></pre> <p>against both parent window and the HTML Control HWND which doesn't work either - the keyboard overlays the editable field (no window resize) and the window doesn't accept any more messages (hung) </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload