( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question )
Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form.
Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible.
It seems like the repainting is not working, on initial startup of the form.
As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each.
Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing.
I then ran wine using 'wine --debugmsg +edit programname' for both app's.
I see both logging 'Creating ANSI edit control, style = xxxxx'
but the style reference is different between apps - I am not sure if this the cause or not.
The problem app reports style = 54011104 and the basic app shows style = 50010080.
Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ?
What other wine class debugmsg types should I use to narrow down the source of this problem ?
Is there anyway I can check to see how the database app is repainting text within the text edit components ?
Regards
Doug Herbert.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Thu, Sep 18, 2003 at 08:41:19PM -0700, Doug Herbert wrote:
( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question )
Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form.
Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible.
Hi Doug,
It's possible that this might help.
Huw.
It's possible that this might help.
Huw.
case WM_MOUSEACTIVATE:
/** FIXME: maybe DefWindowProc() > -
SetFocus(hwnd);
result = MA_ACTIVATE; break;
SetFocus(es->hwndSelf);
Thanks for the reply. I have recompiled my wine version ( 20030911 from winehq ) but it did not help.
Dumb question, but the suggested patch would only affect mouse over ? I tried mouse over, but the text is only painted when I tab into the field - either by clicking on the field or using the tab key.
( aside : the reason for my mention of a simple windows app here, is an aid only to see a working example, of a text edit box displaying text, before that editbox has focus.
Compared with the real windows app I am trying to diagnose )
I have done some more tracing and notice that the EDIT_PaintLine debug message is only displayed when I activate the field.
In the basic window app I compiled, this EDIT_PaintLine message is displayed on form startup ( I do not manually activate the fields in my simple app - though this seems one solution - only problem the database app is one we have purchased off a third party, so no acccess to the source.
The database app ( the one with this painting edit box problem ) does log
--- snip ----
trace:edit:EditWndProc_common hwnd=0x40026 msg=c wparam=0 lparam=419318b9 trace:edit:EDIT_WM_SetText L"This is textbox 3" trace:edit:EDIT_EM_ReplaceSel L"This is textbox 3", can_undo 0, send_update 0 trace:edit:EDIT_MakeFit trying to ReAlloc to 17+1 characters trace:edit:EDIT_MakeFit Old 32 bit handle 0x404efd5a, new handle 0x404efd5a trace:edit:EDIT_MakeFit We now have 31+1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 0, strl 17, selstart 0 ('L""'), text 'L""')
but the following does not happen until the edit field is activated. ( then we can see the text )
trace:edit:EDIT_WM_SetFocus notification EN_SETFOCUS sent to hwnd=0x40025 err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicode (virtKey=9,scanCode=F,keycode=17,state=1) trace:edit:EditWndProc_common hwnd=0x40026 msg=f wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x40026 msg=14 wparam=730 lparam=0 trace:edit:EDIT_PaintLine line=0
---- snip -----
do when the edit box has focus, I now see the text 'This is textbox 3'
Regards
Doug.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
further,
the following edit control debugmsg from my simple app has two lines, probably worth of discussion - the last two in the following log extract :
---snip---
trace:edit:EDIT_WM_SetText L"more text by Doug" trace:edit:EDIT_EM_ReplaceSel L"more text by Doug", can_undo 0, send_update 0 trace:edit:EDIT_MakeFit trying to ReAlloc to 17+1 characters trace:edit:EDIT_MakeFit Old 32 bit handle 0x404ad022, new handle 0x404ad022 trace:edit:EDIT_MakeFit We now have 31+1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 0, strl 17, selstart 0 ('L""'), text 'L""') trace:edit:EDIT_WM_SetText notification EN_CHANGE sent to hwnd=0x10023 trace:edit:EDIT_WM_SetText notification EN_UPDATE sent to hwnd=0x10023
---snip ---
I do not see these SetText notifications in the problem app. How are these notifications triggered ?
I am currently reading through the controls/edit.c source, to understand how this control repaints itself.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
-
Doug Herbert -
George Ginden -
Huw D M Davies