Aric Stewart 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 surro
On 5/7/13 8:15 AM, Dmitry Timoshkov wrote:
> Aric Stewart 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
Aric Stewart 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.
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 android
Suresh Murty 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.
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
---
dlls/user32/
ue, 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 the kinks out.
For more
t know if I trust the bot at the moment, but it says the tests
> failed here...
> I'll rerun them to see if the failure is repeatable.
>
> -- Forwarded message --
> From:
> Date: Tue, Oct 11, 2011 at 1:21 PM
> Subject: Re: 79794: Help Test Please: use uniscr
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 incorrec
Henry Kroll III 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 -/+10,-/+1 com
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 i
On 12/15/2009 15:52, Roderick Colenbrander wrote:
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov 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 wind
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov 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 say
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
redi
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 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 that
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 Sivov
>>> wrote:
>>>
On 12/13/2009 15:15, Roderick Colenbrander wrote:
>>> The main test which AJ suggested would be t
On 12/14/2009 18:19, André Hentschel wrote:
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov 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. T
Roderick Colenbrander schrieb:
> On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov 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
> Regis
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 us
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov 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 say
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
>> 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 wit
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 cont
On Sun, Dec 13, 2009 at 11:48 AM, Nikolay Sivov wrote:
> On 12/13/2009 13:08, Roderick Colenbrander wrote:
>>
>> On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov
>> wrote:
>>
>>>
>>> Hi.
>>>
>>> Yesterday I looked at XP introduced messages for Edit controls
>>> (EM_SETCUEBANNER/EM_GETCUEBANNER).
>
On 12/13/2009 13:08, Roderick Colenbrander wrote:
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov 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
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov 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 comments are
>
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
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 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 wher
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" 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;
+LPTSTR lptStrCop
"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
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) || (s
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 @
"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,
> GetDesktop
"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(nam
>
> 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)
@@ -
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
"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. Yo
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.
>
"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/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 chec
"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
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 a
"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/s
"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 = S
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_SETS
"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);
+SendMessage(h
"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
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
ed
Hi,
Sorry, I meant:
ChangeLog:
Fixed dropdown combo creation when there is NO space for an edit
control.
-- Ph.
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 e
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 nee
On 05.09.2005 11:23, Michael Kaufmann wrote:
> Hi,
>
> Does Windows XP use Unicode controls too if theming is on?
Yes. (Technically, it uses Unicode controls when comctl 6.0 is used.)
-f.r.
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 wit
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 me
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
d be no problem 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'
is issue ?
I've 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
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 its
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
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 non-client area goes to
zero.
ChangeLog:
Ulrich Czekal
rotect read-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);
brea
edit.c
===
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 */
> It's OK. It's good that you acknowladge the problem,
> this is the first step to recovery :)
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 ru
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
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 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 s
72 matches
Mail list logo
