Microsoft Forms 2.0 Text Box

Rolan Paul K. Veron Cruz

unread,

Mar 18, 1998, 3:00:00 AM3/18/98

to

Hello

I've put in an OLE Control, an MS Forms 2.0 Text Box, into my dialog
resource. When I run it, it doesn't allow me to type text into it, unlike
an ordinary edit box. Does this mean I have to override the KeyDown,
KeyPress, or Change functions, then call GetText() and SetText() to update
the contents of this control? I've tried calling SetLocked() and
SetEnabled(), but nothing seems to work.

Thanks a million

Harlan Seymour

unread,

Mar 24, 1998, 3:00:00 AM3/24/98

to

You are out of luck. I have called MS support on this, and the answer is
that VB and VBA play tricks to make the MS Forms 2.0 Text Box work, and MS
will not reveal how to do it. In other words they are using unpublished API
calls (that are non-generic and might even be non-ActiveX). If you ever
find a way around this problem, I would also love to know the solution.

Regards,
Harlan

--
- Harlan R. Seymour, HYPERCUBE, INC.
- +1 310 559 2354, Fax: 559 2357
- mailto:har...@hcube.com, http://www.hcube.com
--

Rolan Paul K. Veron Cruz wrote in message
<01bd5284$6070ae40$99a18ed0@tripper>...

Steve Danielson

unread,

Mar 25, 1998, 3:00:00 AM3/25/98

to

Hi,

Here is a workaround for this problem:

Problem:
fm20.dll's text and combo-box controls don't properly respond to
WM_GETDLGCODE message.
These controls don't seem to handle this message at all.

Explanation:

MFC source, file OCCDLG.CPP function produces incorrect message routing for
WM_CHAR
messages:

BOOL COccManager::IsDialogMessage(CWnd* pWndDlg, LPMSG lpMsg)
{

...

case WM_CHAR:
// Ignore chars sent to the dialog box (rather than the control).
if (pWndMsg == pWndDlg)
return TRUE;

code = GetDlgCode(pWndMsg, lpMsg);
^^^^^^^^^^^^^^^^^^^^^------------------------- value of code is always 0
which is
most likely incorrect. It should be
DLGC_WANTCHARS or DLGC_WANTMESSAGE.

// If the control wants to process the message, then don't check
// for possible mnemonic key.
if ((lpMsg->message == WM_CHAR) &&
(code & (DLGC_WANTCHARS | DLGC_WANTMESSAGE)))
break;

...

Workaround:

Luckily, there seems to be a workaround which seems to correct WM_CHAR
routing for
these controls:

// SECScriptHostView is Stingray's (http://www.stingray.com )view that hosts
ActiveX controls as a part of our Objective Toolkit Pro

BOOL SECScriptHostView::PreTranslateMessage(MSG* pMsg)
{
ASSERT(pMsg);

if(pMsg->message==WM_CHAR)
return FALSE;

// Grab the WM_KEYDOWN to provide our own accelerators without
// forcing the application writer to sacrifice his/her
// existing accel table
BOOL bDefProcessing=TRUE;
if(pMsg->message==WM_KEYDOWN)
bDefProcessing=OnPreTranslateChar((UINT)pMsg->wParam,(LONG)pMsg->lParam);

if(bDefProcessing)
return CFormView::PreTranslateMessage(pMsg);
else return TRUE;
}

Add this PreTranslateMsg override to your dlg that is hosting the forms
controls and you will be all set!
--
Steve Danielson
Stingray Software, Inc.
http://www.stingray.com

Harlan Seymour wrote in message
<#bLJ556V...@uppssnewspub05.moswest.msn.net>...

Steve Danielson

unread,

Mar 25, 1998, 3:00:00 AM3/25/98

to

Hi,

Here is a workaround for this problem (this may be posted twice. I took too
long to answer the 1st time and my connection was severed)

Explanation:

...

Workaround:

// SECScripthostView is a part of Stingray's Objective Toolkit PRO

BOOL SECScriptHostView::PreTranslateMessage(MSG* pMsg)
{
ASSERT(pMsg);

if(pMsg->message==WM_CHAR)
return FALSE;

// Grab the WM_KEYDOWN to provide our own accelerators without
// forcing the application writer to sacrifice his/her
// existing accel table
BOOL bDefProcessing=TRUE;
if(pMsg->message==WM_KEYDOWN)
bDefProcessing=OnPreTranslateChar((UINT)pMsg->wParam,(LONG)pMsg->lParam);

if(bDefProcessing)
return CFormView::PreTranslateMessage(pMsg);
else return TRUE;
}

Add this PreTranslateMsg override to your dlg class, and this will be
resolved.

Thanks,