Aric Stewart a...@codeweavers.com wrote:
dlls/user32/edit.c | 21 +
include/imm.h | 9 +
2 files changed, 30 insertions(+)
Using usual 4 spaces indentation would slightly improve the readability.
--
Dmitry.
On 5/7/13 8:15 AM, Dmitry Timoshkov wrote:
Aric Stewart a...@codeweavers.com wrote:
dlls/user32/edit.c | 21 +
include/imm.h | 9 +
2 files changed, 30 insertions(+)
Using usual 4 spaces indentation would slightly improve the readability.
Maybe, but
Aric Stewart a...@codeweavers.com wrote:
dlls/user32/edit.c | 21 +
include/imm.h | 9 +
2 files changed, 30 insertions(+)
Using usual 4 spaces indentation would slightly improve the readability.
Maybe, but I always to match the styling of the
Suresh Murty murtys.w...@gmail.com wrote:
Sends a EM_SETSEL message after the initial text has been set.
This is wrong place for both a test and a fix. The text should be
selected on focus by a dialog control itself.
--
Dmitry.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19988
Your paranoid
...@kegel.com
Date: Tue, Oct 11, 2011 at 1:21 PM
Subject: Re: 79794: Help Test Please: use uniscribe in the single line
edit control
To: d...@kegel.com, wine-tests-resu...@winehq.org
This is an experimental automated build and test service.
Please feel free to ignore this email while we work
Apologies I sent this to the wrong list just now.
Ok, Thanks to Dan I have found and corrected the issues that this
created with the tests. I believe all the tests should continue to pass
with this version of the patch.
Has anyone tried it live in any applications?
-aric
---
line
edit control
To: d...@kegel.com, wine-tests-resu...@winehq.org
This is an experimental automated build and test service.
Please feel free to ignore this email while we work the kinks out.
For more info about this message, see http://wiki.winehq.org/BuildBot
The Buildbot has detected
This patch is experimental but people had some interest in testing it
and I would love some more testing.
What is currently known not to be working:
* Tabs
* Font Fallback
* Complex composed glyphs are not breaking or highlighting properly.
Testing is appreceated. Send me crashes or
Henry Kroll III he...@comptune.com wrote:
+if (es-region_posx 0)EDIT_EM_LineScroll(es,-10,0);
+else if (es-region_posx 0)EDIT_EM_LineScroll(es,10,0);
+if (es-region_posy 0)EDIT_EM_LineScroll(es,0,-1);
+else if (es-region_posy 0)EDIT_EM_LineScroll(es,0,1);
Where do
On 12/15/2009 15:52, Roderick Colenbrander wrote:
Great that you got it working. Regarding actctx, this should work fine
with our manifest support. Not much has to happen at all. Basically in
user32 it needs to be checked whether a window class (lets say the
Button one) is redirected or not. If
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets say the Button control would be
redirected using a manifest.
If I got
Nikolay Sivov schrieb:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets say the Button control would be
redirected using a
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov bungleh...@gmail.com wrote:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets
On 12/15/2009 15:52, Roderick Colenbrander wrote:
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivovbungleh...@gmail.com wrote:
Great that you got it working. Regarding actctx, this should work fine
with our manifest support. Not much has to happen at all. Basically in
user32 it needs to be
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov bungleh...@gmail.com wrote:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
On 12/14/2009 18:19, André Hentschel wrote:
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivovbungleh...@gmail.com wrote:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call
Nikolay Sivov schrieb:
On 12/14/2009 18:19, André Hentschel wrote:
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivovbungleh...@gmail.com
wrote:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to
On 12/14/2009 19:56, André Hentschel wrote:
Nikolay Sivov schrieb:
Alexandre told me, that he just wants to see that this test works, but
its not necessary to add it to wine.
I ran into to some issues where windows needed a signed dll to use a
manifest with it. I dont know how to manage
Hi.
Yesterday I looked at XP introduced messages for Edit controls
(EM_SETCUEBANNER/EM_GETCUEBANNER).
This definitely doesn't work without v6 module loaded.
Does someone have any idea how this supposed to work? Any comments are
welcome as usual.
P.S. Yes, I know that comctl32 does subclass
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov bungleh...@gmail.com wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls
(EM_SETCUEBANNER/EM_GETCUEBANNER).
This definitely doesn't work without v6 module loaded.
Does someone have any idea how this supposed to work? Any
On 12/13/2009 13:08, Roderick Colenbrander wrote:
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivovbungleh...@gmail.com wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls
(EM_SETCUEBANNER/EM_GETCUEBANNER).
This definitely doesn't work without v6 module loaded.
Does
On Sun, Dec 13, 2009 at 11:48 AM, Nikolay Sivov bungleh...@gmail.com wrote:
On 12/13/2009 13:08, Roderick Colenbrander wrote:
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivovbungleh...@gmail.com
wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls
On 12/13/2009 14:27, Roderick Colenbrander wrote:
Correct the current theming code is broken like hell and needs to be rewritten.
So as I thought.
It is possible to write some tests but it will mostly be tests that
won't make it into Wine itself. The easy test is just to test whether
a
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets say the Button control would be
redirected using a manifest.
If I got it right you're talking about a dummy dll with
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets say the Button control would be
redirected using a manifest.
If I got
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov bungleh...@gmail.com wrote:
On 12/13/2009 15:15, Roderick Colenbrander wrote:
The main test which AJ suggested would be to 'force' native user32 to
call RegisterClassNameW. There would be a dummy dll containing a
RegisterClassNameW to which lets
On 12/13/2009 01:46 PM, Nikolay Sivov wrote:
Could you suggest a best way to generate dll on runtime, maybe it's
possible to place in into resourse?
Any examples are welcome.
dlls/kernel32/tests/file.c has create_fake_dll() and
dlls/kernel32/tests/loader.c has test_Loader(), maybe that's of
Please don't commit this test. Instead use or comment next try:
user32: Destroy EDITSTATE structure in the WM_NCDESTROY message processing
--
Best regards,
Ilya Shpigor.
On 11/13/09, Ilya Shpigor shpi...@etersoft.ru wrote:
Hi,
There is a problem to get edit control text after It has processed
WM_DESTROY
message. Perhaps, problem with EDITSTATE structure what contain this text.
WM_DESTROY cause destroying this structure.
This is currently a place where
Michael Martin wrote:
This patch adds test for edit control clipboard context menu.
The test passes on Windows XP as the WM_COMMAND message is not sent to
the edit control by its context menu.
Fails on wine because wine does incorrectly send that message.
This problem shows up using the edit
Michael Martin martinm...@hotmail.com wrote:
+WNDPROC editWndProc;
Should be static.
+static INT_PTR CALLBACK edit_control_wndproc(HWND hwnd, UINT msg, WPARAM
wparam, LPARAM lparam)
INT_PTR is wrong return type for a window proc.
+{
+static int timerCount = 0;
+HGLOBAL cbData;
Hi Aric,
Just a suggestion:
@@ -1818,6 +1818,7 @@ static void EDIT_ML_InvalidateText(EDITSTATE
*es, INT start, INT end)
RECT rcUpdate;
INT l;
+ if (vlc == 0) vlc = 1;
if ((el es-y_offset) || (sl es-y_offset + vlc))
return;
@@ -2235,6 +2236,7 @@
Great idea, patch resubmitted.
-aric
Juan Lang wrote:
Hi Aric,
Just a suggestion:
@@ -1818,6 +1818,7 @@ static void EDIT_ML_InvalidateText(EDITSTATE
*es, INT start, INT end)
RECT rcUpdate;
INT l;
+ if (vlc == 0) vlc = 1;
if ((el es-y_offset) || (sl
Aric Stewart [EMAIL PROTECTED] wrote:
+static inline INT calculate_vlc(EDITSTATE *es)
+{
+ INT vlc = (es-format_rect.bottom - es-format_rect.top) / es-line_height;
+return max(1,vlc);
+}
The formatting of the above hunk is broken, you will notice that
once you set tab size in your
Ilya Shpigor [EMAIL PROTECTED] wrote:
- /* why do we notify to es-hwndParent, and we send this one to GetParent()?
*/
-hbrush = (HBRUSH)SendMessageW(GetParent(es-hwndSelf), msg,
(WPARAM)hdc, (LPARAM)es-hwndSelf);
+/* We must send all notifies to es-hwndParent.
+ *
Ilya Shpigor [EMAIL PROTECTED] wrote:
+static void test_edit_parent_desktop_1(void)
+{
+HWND hwEdit;
+HDC hdc;
+
+hwEdit = CreateWindowEx( 0, EDIT, NULL, WS_CHILD | WS_OVERLAPPEDWINDOW
|
WS_VISIBLE, 10, 10, 300, 300,
GetDesktopWindow(),
Lei Zhang [EMAIL PROTECTED] writes:
+static BOOL EDIT_IsInsideDialog(EDITSTATE *es)
+{
+static WCHAR dialog_class[] = {'#','3','2','7','7','0',0};
+WCHAR name[8];
+int r;
+
+r = GetClassNameW(es-hwndParent, name, 8);
+if (r 0)
+if (!lstrcmpW(name,
It seems like there's a missing region invalidation in the edit control
somewhere; the background is not correctly updated, unless the window is
moved or exposed to X11 exposes. See screenshot at
http://www.cendio.com/~astrand/wine/46-textedit-color/nopaint.png. In this
case, xclock has been
It seems like there's a missing region invalidation in the edit control
somewhere; the background is not correctly updated, unless the window is
It seems like this patch fixes the problem:
--- edit.c (revision 13229)
+++ edit.c (arbetskopia)
@@ -5215,6 +5215,8
Lei Zhang [EMAIL PROTECTED] wrote:
I'll add EM_GETSEL checks as well.
I'm sorry, but in your latest patch you have added only one EM_GETSEL,
but that's not after every message as repeated in each my mail.
--
Dmitry.
On 9/11/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Lei Zhang [EMAIL PROTECTED] wrote:
I'll add EM_GETSEL checks as well.
I'm sorry, but in your latest patch you have added only one EM_GETSEL,
but that's not after every message as repeated in each my mail.
--
Dmitry.
I feel after
Lei Zhang [EMAIL PROTECTED] wrote:
I feel after every message is bloating the test too much. If we take
the approach where we believe anything can go wrong and check
everything after every message, then we'll spend the rest of our lives
writing tests.
That's certainly an exaggeration. You've
On 9/10/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Lei Zhang [EMAIL PROTECTED] wrote:
In the tests still there is no actual edit contents/selection changes
tracking after every message.
--
Dmitry.
I'm sending WM_GETTEXT to the control and then checking the text after
every
Lei Zhang [EMAIL PROTECTED] wrote:
This patch lets users hit ctrl + Z in edit controls to trigger an
undo. The test case has been improved to check for both the return
values and the content of the edit control.
In the tests still there is no actual edit contents/selection changes
tracking
On 9/10/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Lei Zhang [EMAIL PROTECTED] wrote:
This patch lets users hit ctrl + Z in edit controls to trigger an
undo. The test case has been improved to check for both the return
values and the content of the edit control.
In the tests still
Lei Zhang [EMAIL PROTECTED] wrote:
In the tests still there is no actual edit contents/selection changes
tracking after every message.
--
Dmitry.
I'm sending WM_GETTEXT to the control and then checking the text after
every change. Did you mean something else when you say contents
changes
Lei Zhang [EMAIL PROTECTED] wrote:
This patch lets users hit ctrl + Z in edit controls to trigger an
undo. The test case has been improved to check for return values when
appropriate.
+/* select all, cut (ctrl-x), undo (ctrl-z) */
+SendMessage(hwEdit, EM_SETSEL, 0, -1);
+r =
Lei Zhang [EMAIL PROTECTED] wrote:
This lets users hit ctrl + z in edit dialogs. A test case is included.
This should fixed bug 9525.
+/* select all, cut (ctrl-x), undo (ctrl-z) */
+SendMessage(hwEdit, EM_SETSEL, 0, -1);
+SendMessage(hwEdit, WM_CHAR, 24, 0);
+
On 8/30/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Lei Zhang [EMAIL PROTECTED] wrote:
This lets users hit ctrl + z in edit dialogs. A test case is included.
This should fixed bug 9525.
+/* select all, cut (ctrl-x), undo (ctrl-z) */
+SendMessage(hwEdit, EM_SETSEL, 0, -1);
+
James Hawkins [EMAIL PROTECTED] wrote:
+text = MSI_RecordGetString( rec, 10 );
+if ( text )
+{
+begin = strchrW( text, '{' );
+end = strchrW( text, '}' );
Perhaps it would be cleaner to use
end = strchrW( begin, '}' );
--
Dmitry.
Hello,
Byeong-Sik Jeon wrote:
I tested for this patch with the patched Xlib(XFilterEvent deadlock
problem with XInitThreads).
https://bugs.freedesktop.org/show_bug.cgi?id=1182
https://bugs.freedesktop.org/attachment.cgi?id=4874
Changelog:
Update the edit control when the IME
I went ahead and took a bunch more measurements of font margins in the
edit control. These are all taken on real Win2k using traces added to
the conformance test test_margins_font_change, and cross compiled with
MinGW. So here they are for posterity.
The results are rather confusing to me
Huw D M Davies [EMAIL PROTECTED] writes:
Huw Davies [EMAIL PROTECTED]
edit: Only adjust the margins if the edit control is above a certain
size.
This breaks the tests here:
edit.c:788: Test failed: got 0
edit.c:789: Test failed: got 0
edit.c:802: Test failed: got 0
Hi,
Sorry, I meant:
ChangeLog:
Fixed dropdown combo creation when there is NO space for an edit
control.
-- Ph.
Hi,
Does Windows XP use Unicode controls too if theming is on?
Because the Delphi edit controls are now in Unicode mode, the messages
sent to them have to be translated from ANSI to Unicode and back. When a
program reads the Text property of a TEdit control, Delphi sends a
WM_GETTEXTLENGTH
On 05.09.2005 11:23, Michael Kaufmann wrote:
I think you could use SendMessageW instead of calling the window proc
directly.
Yeah... since UnmapMsg32ATo32W is used for both in-process and
inter-process communications, just using SendMessageW() is more correct
and less hassle than messing with
But apart from that, why is the patch not CVS-worthy?
Due how the WM_GETTEXT is dispatched (ie calling the proc) - but that
would be solved with SendMessageW().
I've found another problem: Reading the window proc address with
GetWindowLong won't work for subclassed windows. We need
On 05.09.2005 14:49, Michael Kaufmann wrote:
I've found another problem: Reading the window proc address with
GetWindowLong won't work for subclassed windows. We need to pass the
window proc as a parameter to UnmapMsg32ATo32W (and probably also to
other mapping functions).
Maybe it's even
because
WM_GETTEXTLENGTH only returns an upper limit of the text size, but
Delphi doesn't regard this fact). Because Delphi does NOT use
zero-terminated strings, Delphi will return a string that has twice the
size of the text in the edit control and contains a '\0' character. If
the application
On 04.09.2005 16:47, Michael Kaufmann wrote:
Hi Frank,
One of your theming patches (
http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused
a problem in many Delphi applications. The edit controls of Delphi
applications are now created in Unicode mode. I hope you have an
noticed that this code paints a perfect edit control, with its
background color (for the whole area).
4545 es-style = ~WS_BORDER;
While the following code in place of the line above, doesn't fill the
whole edit with the background color, but the area behind the text
inside
Ulrich Czekalla wrote:
Currently the code always removes its internal WS_BORDER flag so it
doesn't paint its own border. Basically it leaves it to the default
nonclient handler. But it should only do this if WS_EX_CLIENTEDGE is
set. Otherwise it removes the WS_BORDER style and paints the border
On Wed, Sep 15, 2004 at 06:27:11PM +0100, Robert Shearman wrote:
Ulrich Czekalla wrote:
Running some tests under WinXP I noticed that if the edit control doesn't
have WS_EX_CLIENTEDGE it looses the WS_BORDER style and it handles painting
the border. This also has the side effect that it's
===
RCS file: /home/wine/wine/dlls/user/edit.c,v
retrieving revision 1.1
diff -u -r1.1 edit.c
--- dlls/user/edit.c31 Aug 2004 01:10:08 - 1.1
+++ dlls/user/edit.c9 Sep 2004 13:01:26 -
@@ -3604,7 +3604,8 @@
/* Protect read-only edit control from modification */
if(es
-only edit control from modification */
- if(es-style ES_READONLY)
- return;
-
control = GetKeyState(VK_CONTROL) 0x8000;
switch (c) {
@@ -3647,10 +3643,12 @@
SendMessageW(es-hwndSelf, WM_COPY, 0, 0);
break;
case 0x16: /* ^V
On March 28, 2004 5:22 am, Lionel Ulmer wrote:
+static const char *EditWndProc_dump_msg_name(UINT msg)
That's a nice effort, but this is real long name...
What about dbgstr_msg()? Also, this is a real useful
function, I think we should have a standard dbgstr_msg()
function that knows about all
On Sun, Mar 28, 2004 at 11:24:44AM -0500, Dimitrie O. Paun wrote:
On March 28, 2004 5:22 am, Lionel Ulmer wrote:
+static const char *EditWndProc_dump_msg_name(UINT msg)
That's a nice effort, but this is real long name...
I am corrupted by my day job's coding rules which encourages long
On March 28, 2004 11:52 am, Lionel Ulmer wrote:
That's a nice effort, but this is real long name...
I am corrupted by my day job's coding rules which encourages long function
name (thank god Meta-/ exists :-) ).
It's OK. It's good that you acknowladge the problem,
this is the first step to
It's OK. It's good that you acknowladge the problem,
this is the first step to recovery :) g
We will see what AJ says about the 'global' trace function to see if I
resubmit or not (anyway, I forgot the '#undef FE' line, so I may resubmit
anyway).
Not sure where to put this, we may need to run
70 matches
Mail list logo
