Re: Patches / a proposal for the mystic DIB engine
As a returning GSoC student, I had asked about this last year: It's primarily the student's responsibility to work out the conflicts, but it'd be best for you two to talk to one another. The student's obligation is do do what they said they would, so if you complete their proposal for them it doesn't count as them doing it - they'd have to write an implementation of their own, even if it wasn't accepted, which would be a waste. However, as long as their mentor is fine with it, it's acceptable to modify their goals - so perhaps they can add more features or otherwise produce a better DIB engine by working with you and the code you've written. If the mentor thinks they've done enough work over the summer, they'll be paid - even if it's different than what they originally proposed. --Matt Finnicum On 4/11/07, Felix Nawothnig [EMAIL PROTECTED] wrote: Oops. Forgot the patches. Here they are. And the very second I sent the last E-Mail the DIB engine work got accepted as a SoC project (by someone else)... I've no idea what this means to me. Someone clarify please. :)
Re: Richedit URL hyperlink bug
Hi, The problem is most likely in that there's two kinds of links happening at once - the automatically detected one and the manually specified one. The automatic detection is done in ME_AutoURLDetect at the very bottom of editor.c. I don't really have time to look at it myself until this weekend (yay exams). I did notice one strangeness really quick though: curf_ef = cur_format.dwEffects link.dwEffects; def_ef = default_format.dwEffects link.dwEffects; link_ef = link.dwEffects link.dwEffects; Usually you're supposed to check that a dwEffect is included in the dwMask before using it. Also, that third line does... nothing? :) A better way might be: curf_ef = (cur_format.dwEffects cur_format.dwMask) CFE_LINK; def_ef = (default_format.dwEffects default_format.dwMask) CFE_LINK; link_ef = (link.dwEffects link.dwMask) CFE_LINK; I don't know if that's related to your problem, I can look into it this weekend if it's still needed. If you don't find the problem yourself, make sure to make a bug report and link to an executable that demonstrates this :) --Matt Finnicum On 4/9/07, Andrew Talbot [EMAIL PROTECTED] wrote: Hi, I run an app (Blitzin2) that displays scrolling text with various highlightings in a rich edit control. When displaying hyperlinks comprising normal words, they are rendered in blue and underlined, and whatever follows is rendered appropriately. However, if the displayed link text happens to constitute a URL, the blue-underlining doesn't get switched off at the end of the link, so all subsequent text is rendered in blue and underlined. Examples: This is a _link_ to somewhere. (This renders fine.) Visit _www.winehq.org_ to learn about a great piece of software. (This stays blue-underlined after the link.) I thought I would post this here first, in case anyone knows exactly where that is. Thanks, -- Andy.
Re: Want to be a Wine mentor for Google Summer of Code 2007?
They had Wine listed last night when they first started posting the projects (the list was only five projects long), but then they removed the whole list for a while so they could finish preparing it. So I'm assuming we'll be added from that as well. --Matt On 3/15/07, James Hawkins [EMAIL PROTECTED] wrote: On 3/15/07, Maarten Lankhorst [EMAIL PROTECTED] wrote: Kai Blin schreef: On Tuesday 13 March 2007 08:29, Dan Kegel wrote: I'm looking for active Wine developers to act as mentors for Google Summer of Code 2007. If you're interested, please let me know quickly; the list has to be finalized in the next half-day or so. (Sorry for the late notice; I wasn't paying attention, and the deadline snuck up on me...) Looks like we were too late then? We're not on the list of mentoring projects this year, it seems. Cheers, Kai Seems that way, looks like we indeed missed them, is it still possible to participate for soc 2007 with wine, or do we have to wait till next year? Read Dan's earlier post: I'm fine this year, but considering how I missed the deadline (we were saved by LH's kindness), I'm assuming we'll be added. Correct me if I'm wrong, Dan. -- James Hawkins
Re: Forum proposal
But there's one thing with forums that IMVHO mailing-lists can't do. TBMS forums build better comunities than mailing-lists. Mailing lists are just concentrated on the topics, disallowing any OT. With a forum you can easily moderate a on-topic only subforum, allowing people to exchange opinions in other forums. Have you ever logged onto the IRC channels? Their seems to be a healthy community built up around them. --Matt Finnicum (aka 'murph')
Re: Questions concering an application I maintain
On 1/19/07, Jacob Alberty [EMAIL PROTECTED] wrote: I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?). Jacob, If you have any specific issues with wine's richedit control, you can always file a bug on bugs.winehq.org (and be sure to mark it as in the wine-richedit component). I haven't personally tried any api spy programs, so I can't vouch for them - but I've usually had success with just using the environmental variable WINEDEBUG (WINEDEBUG=+richedit wine application.exe). If you have any questions about how the richedit component works, feel free to ask me directly. When making changes, we encourage writing tests (see the dlls/riched20/tetsts folder) to demonstrate that the new behavior is, in fact, the correct behavior. Also, when you make a change make sure to run the tests already there to make sure you haven't caused any existing tests to fail. Thanks, --Matt
Re: riched20: block recursive notification
On 12/30/06, Clinton Stimpson [EMAIL PROTECTED] wrote: This patch blocks riched20 from recursivly sending an EN_CHANGE notification. Fixes bug 6985. Thanks, Clinton Stimpson ChangeLog Block recursive EN_CHANGE notifications. If you're adding a new variable to the ME_TextEditor structure then you should probably also initialize it in ME_MakeEditor. Naming the variable notify is somewhat ambiguous, and there seems to be an established convention of naming int's with the 'n' prefix, like nNotifiy. You should probably comment to explain what the variable is for or attempt to name it something more self evident. Maybe a BOOL would be more appropriate, unless you're intending to extend this to other notify calls as well. Lastly, I don't see why this patch is needed - it only prevents the ME_SendOldNotify (which just calls SendMessageA) from triggering another call of that same EN_CHANGE notification. I don't see why calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe the application you're working with, in processing the EN_CHANGE message, is sending another message to which we wrongly are sending an EN_CHANGE notification - so thus we should fix our message handling of that. A quick look at MSDN shows that The EN_CHANGE notification message is sent when the user has taken an action that may have altered text in an edit control. - it seems that we may be sending them whenever any action (user or not) has altered text in the control. We really could use some tests to see what should generate EN_CHANGE messages. Another possibility is that we don't handle the case where (again, from MSDN) The EN_CHANGE notification is not sent when the ES_MULTILINE style is used and the text is sent through WM_SETTEXT. - perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in response to the EN_CHANGE notification? Thanks for your help with richedit, --Matt Finnicum
Re: [5/5] usp10: remote todo_wine
I think that what James Hawkins had meant something like this: Apply patch one, run the tests. If patch one fixed any of them, remove the todo_wine's for those tests as a part of patch one. Otherwise, leave them todo_wine. Apply patch two, run the tests. If patch two fixed any of them, remove the todo_wine's for those tests as a part of patch two. Etc. This way, if someone builds wine at any step of applying the five patches then the todo_wine's will reflect the current status of if the functions work or not. I think this is important for regression testing. Of course, this will cause troubles if the patches are applied out-of-order or the later patches are applied without the first ones - but I think that's acceptable if you note that they should be committed in order. --Matt Finicum On 12/15/06, Clinton Stimpson [EMAIL PROTECTED] wrote: I can change the tests a bit, and change the currently empty functions to return E_NOTIMPL instead of S_OK. Then I can do it piecemeal. Is that how y'all want it? Clint Clinton Stimpson wrote: Ok. There are 4 functions that have to be implemented at the same time in order to not break any tests, because of how the tests were written. A few days ago, I sent a single patch that implemented those 4 functions, including an update of the tests. It wasn't accepted, and it was suggested to break the patch up. But, I can't break it up without breaking the tests. I do have more patches coming after this batch, and those will be smaller and atomic. So I guess I'm back to asking why my original patch wasn't accepted. ?? Should I resend it? Thanks, Clinton James Hawkins wrote: On 12/14/06, Clinton Stimpson [EMAIL PROTECTED] wrote: Hi, Part 5 of 5. Remove many todo_wine's from the tests, now that the functions are implemented. You have to remove the todo_wine's in the same patch that fixes the tests, or the tests will fail for at least one commit. Patches have to be atomic and error free, and a failing test is an error.
Re: fonts:add framework for tahoma font
On 12/10/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Steven Edwards [EMAIL PROTECTED] wrote: Greenville is virtually abandonware and while its not really possible to claim the font was ripped of it still was being developed under the umbrella of the ReactOS project. Even if work on it is revised and completed, until the situation with ReactOS changes I doubt it would make it in to winehq. Greenville's face is substantially is different from Tahoma, the only thing which is similar to Tahoma is character widths, which makes Greenville a compatible replacement of Tahoma. Since I worked for a publishing company for 10 years, and I know how the font faces are being created, I should say that although Greenville has been developed (formally) for ReactOS I don't think that that fact should make it less useable outside of it. Is there an official policy on whether or not Greenville would be accepted into Wine? Way back in September 2004 (and quoted in WWN 241 [1]) it was said that Greenville was written in some expensive program other that fontforge - is that hindering its inclusion? --Murph [1] http://www.kernel-traffic.org/wine/wn20040924_241.txt
Re: riched20: fixes and additional conformance tests for EM_EXSETSEL
Hey,
I'm sorry for not noticing this bug earlier - I have a bad habit of
only browsing bugs listed under wine-richedit. I actually sent in a
patch that fixes this bug before, but it wasn't accepted because I
hadn't marked a test that it causes to fail as todo_wine. Does the
attached patch solve your problem?
The attached patch moves all the logic to ME_SetSelection, so it'll
apply to EM_SETSEL as well as EM_EXSETSEL (they both are supposed to
follow the same special cases), and this way it will contribute to my
further separating functionality from the message handlers into ME_
local functions which is needed to properly implement windowless
controls.
This patch does result in a wrong return if the user sent a
SetSelection beyond the end of the document (windows allows you to
select an imaginary character at the end), but I don't think that's a
problem for anything, and I'll have it working in a couple weeks (I'm
working on improving the selection code in general, a part of which
will allow you to actually select that extra character in our
richedit). I suppose i could just put a small hack in for the
meantime, if anyone cares.
I haven't tried them together yet, but your new tests do look
significantly more comprehensive - well done.
--Matt
On 12/3/06, Lei Zhang [EMAIL PROTECTED] wrote:
Hi,
Changelog:
* Check the input to EM_EXSETSEL
* Fixes bug 6814
* Added more comprehensive conformance tests for EM_EXSETSEL
editor.c | 52 +---
tests/editor.c | 103 +++--
2 files changed, 112 insertions(+), 43 deletions(-)
From fda32ff4aa4e9b5f6ace07d0f7ad8115cdde2360 Mon Sep 17 00:00:00 2001
From: Matt Finnicum [EMAIL PROTECTED]
Date: Sun, 3 Dec 2006 20:47:27 -0600
Subject: [PATCH] riched20: move some selection code from message handler to
ME_SetSelection
---
dlls/riched20/caret.c| 51 ++---
dlls/riched20/editor.c | 32 ++---
dlls/riched20/tests/editor.c |6 -
3 files changed, 40 insertions(+), 49 deletions(-)
diff --git a/dlls/riched20/caret.c b/dlls/riched20/caret.c
index ce3abb7..4709cfc 100644
--- a/dlls/riched20/caret.c
+++ b/dlls/riched20/caret.c
@@ -80,39 +80,52 @@ int ME_GetTextLengthEx(ME_TextEditor *ed
void ME_SetSelection(ME_TextEditor *editor, int from, int to)
{
- if (from == 0 to == -1)
+ int tmp;
+ ME_InvalidateSelection(editor);
+
+ to = max(-1, to);
+ to = min(ME_GetTextLength(editor) +1, to);
+
+ from = max(-1, from);
+ from = min(ME_GetTextLength(editor) +1, from);
+
+ if (from == -1 to == -1)
{
+/* deselect and move caret to end of control */
+editor-pCursors[1].pRun = editor-pCursors[0].pRun =
ME_FindItemBack(editor-pBuffer-pLast, diRun);
+editor-pCursors[1].nOffset = editor-pCursors[0].nOffset = 0;
+ME_ClearTempStyle(editor);
+ }
+ else if (from == 0 to == -1)
+ {
+/* Select all of the text */
editor-pCursors[1].pRun = ME_FindItemFwd(editor-pBuffer-pFirst, diRun);
editor-pCursors[1].nOffset = 0;
editor-pCursors[0].pRun = ME_FindItemBack(editor-pBuffer-pLast, diRun);
editor-pCursors[0].nOffset = 0;
-ME_InvalidateSelection(editor);
-ME_ClearTempStyle(editor);
-return;
- }
- if (from == -1 to == -1) /*-1,-1 means put the selection at the end of
the text */
- {
-editor-pCursors[1].pRun = editor-pCursors[0].pRun =
ME_FindItemBack(editor-pBuffer-pLast, diRun);
-editor-pCursors[1].nOffset = editor-pCursors[0].nOffset = 0;
-ME_InvalidateSelection(editor);
ME_ClearTempStyle(editor);
-return;
}
- if (from == -1)
+ else if (from == -1)
{
+/* deselect and move caret to end of current selection */
editor-pCursors[1] = editor-pCursors[0];
ME_Repaint(editor);
ME_ClearTempStyle(editor);
-return;
}
- if (fromto)
+ else
{
-int tmp = from;
-from = to;
-to = tmp;
+if (fromto)
+{
+ tmp = from;
+ from = to;
+ to = tmp;
+}
+ME_RunOfsFromCharOfs(editor, from, editor-pCursors[1].pRun,
editor-pCursors[1].nOffset);
+ME_RunOfsFromCharOfs(editor, to, editor-pCursors[0].pRun,
editor-pCursors[0].nOffset);
}
- ME_RunOfsFromCharOfs(editor, from, editor-pCursors[1].pRun,
editor-pCursors[1].nOffset);
- ME_RunOfsFromCharOfs(editor, to, editor-pCursors[0].pRun,
editor-pCursors[0].nOffset);
+
+ ME_InvalidateSelection(editor);
+ ME_SendSelChange(editor);
}
diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c
index a8fadc1..4d9a869 100644
--- a/dlls/riched20/editor.c
+++ b/dlls/riched20/editor.c
@@ -1588,10 +1588,7 @@ LRESULT WINAPI RichEditANSIWndProc(HWND
}
case EM_SETSEL:
{
-ME_InvalidateSelection(editor);
ME_SetSelection(editor, wParam, lParam);
-ME_InvalidateSelection(editor);
-ME_SendSelChange(editor);
return 0;
}
case EM_SETSCROLLPOS:
@@ -1617,33 +1614,10 @@ LRESULT WINAPI RichEditANSIWndProc
Re: WM_SETFONT support
On 11/22/06, Jing Li [EMAIL PROTECTED] wrote: Hi, I am building a dialog box which is used to display the license agreement information. I create my dialog template with the dialog editor. The dialog box contains the Microsoft Rich Textbox Control (ActiveX control). When the function DialogBox() is called to display the dialog box, the command WM_SETFONT is sent to my dialog procedure and the dialog box does not pop up at all. Do you know how to deal with this problem? The only information I've got from MSDN is The dialog box procedure is responsible for saving the font handle passed with the WM_SETFONT message and selecting the handle into the display device context whenever it writes text to the window. Thanks a lot for your response and help. Regards, Jing Hello! My first guess would be that it might not actually be a problem with WM_SETFONT - we added support for that in richedit a couple months ago and haven't had any reported problems yet (though it's still possible). A failed setfont call should still just result in the default, ugly font - so the whole dialog not appearing might be a different problem. Have you tested that it'll run properly on windows? If so, have you tried using a native copy of riched20.dll? You should create a bug report on bugzilla (http://bugs.winehq.org/). If it works properly with the native riched20.dll, mark the bug as being in the wine-richedit component. In that case, It'd be very helpful if you could include a +richedit trace, and even more helpful if you could include either test code or a compiled .exe that'd show the problem. Thanks, --Matt Finnicum
Re: Help with git
What I do is to follow along with things on the shortlog: http://source.winehq.org/git/?p=wine.git;a=shortlog Lets say you want to move your current branch to my recent patch riched20: Rewrite of scrolling and some redrawing code. - you'd click the link commit to the right of it. In the page that you'll be taken to, you'll see a line like this: commit abecd9e393925e008449a80ec14682790b29042c you can then do a git reset --hard abecd9e393925e008449a80ec14682790b29042c and your git will be moved to the point in time right after that commit. If you then want to manually apply a patch, click commitdiff to the right of it's entry in the shortlog, followed by plain on the top - this will take you to a plaintext diff of the patch, which you could save to a file and apply with the patch command. (patch -p1 thepatch.diff usualy works well for me) --Matt On 9/9/06, Kapila De Silva [EMAIL PROTECTED] wrote: Hi all, Hope this is the right place to post this, if not, my apologies. Im trying to track down an issue that occurred between 0.9.19 and 0.9.20, and am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well. I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please? Thanks in advance Kapila
Re: Making people aware about appdb and outdated Wine versions.
--SNIP-- Second: Old version of Wine are still quite used because of package managers just offers stable Wine versions over the unstable ones so I would like to see another popup or warning in winecfg that informs user that their Wine is getting old... so after specific number of days(from release of Wine version X) counter gives some warnings about old Wine version. Having a popup (or anything that requires user interaction) could get really irritating - there are situations where people would use an older version of wine on purpose. Like if a large organization uses it to run one specific app, and has a specific version that works perfectly, they might not have any reason to update. How about a fixme when wine is run, informing them that the version they are running was released X long ago, and that if they have any issues they should try a newer version? It'd be nice, too, if people then reported bugs with that on the top of the output - it could save a lot of work chasing down already-fixed issues. --Matt
Re: Re: Making people aware about appdb and outdated Wine versions.
On 9/10/06, Tom Wickline [EMAIL PROTECTED] wrote: If they have any common sense about them they will see that the application database is advertised on the winehq front page and go there on there own. You get out of Wine what you put into it! Most users, as far as I can tell, never goto winehq. They get wine from their distro's package manager, and then when it breaks head to their distro's support / community. - Hide quoted text - As for people contributing to third party forum's and wiki's, that is a double edged sword its nice that they contribute there findings so others can play a game or use a app. I personally don't feel we should discourage people from posting there findings to other sites. But at the same time it would be nice if they contributed that information to our wiki or application database.
Re: riched20: ME_SetSelection -1 to -1 behavior fix
Mark,
This patch, like the first one you submitted, is linewrapped (meaning
it won't apply cleanly). I'd suggest just attaching the patch to your
e-mail, so you don't have to worry about these things.
Also, it's always nice to have a conformance test for things like
this. Perhaps show that it's the correct behaviour for both
EM_EXSETSEL and EM_SETSEL? If you've got any questions on writing one
(or just want me to do it for you), just send me an e-mail.
Thanks for contributing,
--Matt
On 9/2/06, Mark Lu [EMAIL PROTECTED] wrote:
ChangeLog:
* Corrects the behavior of ME_SetSelection when selecting from -1 to -1
---
dlls/riched20/caret.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/dlls/riched20/caret.c b/dlls/riched20/caret.c
index bdab179..06f021c 100644
--- a/dlls/riched20/caret.c
+++ b/dlls/riched20/caret.c
@@ -90,6 +90,14 @@ void ME_SetSelection(ME_TextEditor *edit
ME_ClearTempStyle(editor);
return;
}
+ if (from == -1 to == -1) /*-1,-1 means put the selection at the
end of the text */
+ {
+editor-pCursors[1].pRun = editor-pCursors[0].pRun =
ME_FindItemBack(editor-pBuffer-pLast, diRun);
+editor-pCursors[1].nOffset = editor-pCursors[0].nOffset = 0;
+ME_InvalidateSelection(editor);
+ME_ClearTempStyle(editor);
+return;
+ }
if (from == -1)
{
editor-pCursors[1] = editor-pCursors[0];
--
1.4.1.1
Could I get some permissions for Bugzilla?
Hello, I'm not really sure what levels of permissions Bugzilla has, but could I get the ability to modify bugs? (things like assign them to myself, mark them as fixed, etc). If it's possibile, I suppose only having such access to the wine-richedit component would be fine, too. --Matt Finnicum
Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462
Hi, Is there something wrong with this patch / a reason it's not being accepted? Sorry if this might have been answered this on IRC last night - X died while I was away, so I'd have missed it. Thanks, --Matt Finnicum On 8/19/06, Matt Finnicum [EMAIL PROTECTED] wrote: Hi, I've cleaned up / re-diffed this patch from Brian Chang. It fixes bug 4462 by handling several odd ways in which EM_EXSETSEL can be called. It also make the message return a proper value, not just zero. --Matt Finnicum (Please commit as Brian Chang) The last version of this patch can be found here: http://www.winehq.com/pipermail/wine-patches/2006-March/024976.html --- dlls/riched20/editor.c | 25 +--- dlls/riched20/tests/editor.c | 52 ++ 2 files changed, 73 insertions(+), 4 deletions(-)
Re: riched20: modify ME_CharFromPoint to work properly with password controls
Ad i suppose this should go to wine-patches. Same as the original
patch, but properly destroys the temporary string when it's no longer
needed.
Thanks,
--Matt
On 8/7/06, Matt Finnicum [EMAIL PROTECTED] wrote:
Oops! Good Call, Phil.
Attached is an updated patch.
--Matt
On 8/7/06, Phil Krylov [EMAIL PROTECTED] wrote:
Hi Matt,
On 07/08/06, Matt Finnicum [EMAIL PROTECTED] wrote:
This patch modifies ME_CharFromPoint to work properly with password
controls (the patch i sent in / got committed a couple days ago).
Should not the temp string be freed afterwards?
-- Ph.
From 880850b5980515549833854c81e8d445cba758cb Mon Sep 17 00:00:00 2001
From: Matthew Finnicum [EMAIL PROTECTED]
Date: Mon, 7 Aug 2006 10:12:44 -0400
Subject: [PATCH] riched20: modify ME_CharFromPoint to work properly with
password controls
---
dlls/riched20/run.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/dlls/riched20/run.c b/dlls/riched20/run.c
index d74d68f..f9b1ef6 100644
--- a/dlls/riched20/run.c
+++ b/dlls/riched20/run.c
@@ -512,8 +512,20 @@ int ME_CharFromPoint(ME_TextEditor *edit
}
hDC = GetDC(editor-hWnd);
hOldFont = ME_SelectStyleFont(editor, hDC, run-style);
- GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
-cx, fit, NULL, sz);
+
+ if (editor-cPasswordMask)
+ {
+ME_String *strMasked =
ME_MakeStringR(editor-cPasswordMask,ME_StrVLen(run-strText));
+GetTextExtentExPointW(hDC, strMasked-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ME_DestroyString(strMasked);
+ }
+ else
+ {
+GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ }
+
ME_UnselectStyleFont(editor, hDC, run-style, hOldFont);
ReleaseDC(editor-hWnd, hDC);
return fit;
--
1.4.1.1
Re: riched20: modify ME_CharFromPoint to work properly with password controls
Oops! Good Call, Phil.
Attached is an updated patch.
--Matt
On 8/7/06, Phil Krylov [EMAIL PROTECTED] wrote:
Hi Matt,
On 07/08/06, Matt Finnicum [EMAIL PROTECTED] wrote:
This patch modifies ME_CharFromPoint to work properly with password
controls (the patch i sent in / got committed a couple days ago).
Should not the temp string be freed afterwards?
-- Ph.
From 880850b5980515549833854c81e8d445cba758cb Mon Sep 17 00:00:00 2001
From: Matthew Finnicum [EMAIL PROTECTED]
Date: Mon, 7 Aug 2006 10:12:44 -0400
Subject: [PATCH] riched20: modify ME_CharFromPoint to work properly with
password controls
---
dlls/riched20/run.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/dlls/riched20/run.c b/dlls/riched20/run.c
index d74d68f..f9b1ef6 100644
--- a/dlls/riched20/run.c
+++ b/dlls/riched20/run.c
@@ -512,8 +512,20 @@ int ME_CharFromPoint(ME_TextEditor *edit
}
hDC = GetDC(editor-hWnd);
hOldFont = ME_SelectStyleFont(editor, hDC, run-style);
- GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
-cx, fit, NULL, sz);
+
+ if (editor-cPasswordMask)
+ {
+ME_String *strMasked =
ME_MakeStringR(editor-cPasswordMask,ME_StrVLen(run-strText));
+GetTextExtentExPointW(hDC, strMasked-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ME_DestroyString(strMasked);
+ }
+ else
+ {
+GetTextExtentExPointW(hDC, run-strText-szData, run-strText-nLen,
+ cx, fit, NULL, sz);
+ }
+
ME_UnselectStyleFont(editor, hDC, run-style, hOldFont);
ReleaseDC(editor-hWnd, hDC);
return fit;
--
1.4.1.1
Re: riched20: WM_SETFONT support
On 6/25/06, Krzysztof Foltman [EMAIL PROTECTED] wrote: I'm definitely for using your conformance test code. And WM_GETFONT. Not sure about the rest - the code in my patch is based on implementation of EM_SETCHARFORMAT, so it's basically as good as that one. Actually, GETFONT was a mistake - it turns out it doesn't exist for rich edit controls. 1) You need to rewrap the paragraphs, since line lengths change. Yes, but SetCharFormat already does it internally (run.c:624), so there's no need to explicitly call it again. I had some issues with rewrapping not happening when I was testing with mine, but it appears to be working fine on yours. A long line, after being SETFONT'd to a larger font, would have overlapping text. 2) Your code ignores lParam (which is supposed to specify if it repaints immediately) Ahh. Missed that somehow. 3) You need to invalidate the entire control - otherwise just the are the text takes up will be redrawn - if the text shrinks, then the area outside it's new size won't be blanked / you'll see fragments of the old text. I'm not sure how the original control is behaving - going with InvalidateRect, no matter if it's necessary or not, won't harm. However, it should be done in ME_SetCharFormat, so that both EM_SETCHARFORMAT and WM_SETFONT (and other functions) will use it. Sounds good - I didn't test how SetCharFormat was behaving, but you're right - it's probably needed by both. The redraw glitch can be pretty obvious (just change any chunk of text to a smaller font) 4) Your code (I believe) will reset the scroll position - I store it ahead of time and then restore it. And that is actually wrong - keep in mind that scroll position is expressed in pixels, and the new font may be sometimes much smaller than the old one. I think the scroll position update code belongs to ME_SetCharFormat, and should be added there in a separate patch. Compare WM_SETFONT to EM_SETCHARFORMAT and you'll know why. Sounds good to me. When it is implemented, I'll add a conformance test for the scrolling behaviour, too. The plan is: if my original patch gets accepted, then you can extract the testing code and WM_GETFONT handler which is missing in my implementation and send it as a separate patch. This will avoid the mess related to combining those two patches into one. MMkay. Will do! When this stuff is finished, I'd suggest you try implementing the ES_PASSWORD-related stuff, combined with WM_SETFONT handling it would let us fix a couple Bugzilla reports :) It should be pretty straightforward and independent of other parts of the code. And I'm not going to touch that stuff now. Most Excellent. ES_PASSWORD (actually I wrote about a third of it already) is only supposed to affect single-line controls, but I could always just implement it for all rich edit controls, and that'll right itself when single-line is implemented. That would probably make more sense, as I doubt anything relies on the Does nothing if it's not a single-line control behaviour. Actually, after implementing that there's a bunch of styles I could add somewhat easily, like WS_SETFONT. Thanks for the help / I'll let ya know what I'm working on. --Matt
Re: riched20: WM_SETFONT support
I was just about to send in the same patch when you did. I'll have to
keep you updated on what I'm working on in the future. (You can see
what I'm planning to do for my SoC project at
http://wiki.winehq.org/MatthewFinnicum)
I've attached the patch I was going to send - I suggest we use some
parts of each (either I can merge them into a patch or you can, your
call).
Our code is actually quite similar - though your
ME_CharFormatFromLogFont is definitely superior to mine (I just did
it all in function / was slightly less awesome).
Aside from my conformance tests (Which your patch passed just fine),
my patch covers some extra things:
1) You need to rewrap the paragraphs, since line lengths change.
2) Your code ignores lParam (which is supposed to specify if it
repaints immediately)
3) You need to invalidate the entire control - otherwise just the are
the text takes up will be redrawn - if the text shrinks, then the area
outside it's new size won't be blanked / you'll see fragments of the
old text.
4) Your code (I believe) will reset the scroll position - I store it
ahead of time and then restore it.
Thanks,
--Matt
On 6/24/06, Krzysztof Foltman [EMAIL PROTECTED] wrote:
ChangeLog:
* WM_SETFONT implementation - sets the default font and the font for
the whole pre-existing text
Seems to fix bug 4563 and half of the bug 3917.
Krzysztof
diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c
old mode 100644
new mode 100755
index 50527ca..61ecc72
--- a/dlls/riched20/editor.c
+++ b/dlls/riched20/editor.c
@@ -92,7 +92,7 @@
- EM_SELECTIONTYPE
- EM_SETBIDIOPTIONS 3.0
+ EM_SETBKGNDCOLOR
- - EM_SETCHARFORMAT (partly done, no ANSI)
+ + EM_SETCHARFORMAT (partly done, no ANSI)
- EM_SETEDITSTYLE
+ EM_SETEVENTMASK (few notifications supported)
- EM_SETFONTSIZE
@@ -135,7 +135,7 @@
+ WM_GETTEXT (ANSIUnicode)
+ WM_GETTEXTLENGTH (ANSI version sucks)
+ WM_PASTE
- - WM_SETFONT
+ + WM_SETFONT
+ WM_SETTEXT (resets undo stack !) (proper style?) ANSIUnicode
- WM_STYLECHANGING
- WM_STYLECHANGED (things like read-only flag)
@@ -1442,7 +1442,6 @@ LRESULT WINAPI RichEditANSIWndProc(HWND
UNSUPPORTED_MSG(EM_SETTYPOGRAPHYOPTIONS)
UNSUPPORTED_MSG(EM_SETWORDBREAKPROCEX)
UNSUPPORTED_MSG(EM_SHOWSCROLLBAR)
- UNSUPPORTED_MSG(WM_SETFONT)
UNSUPPORTED_MSG(WM_STYLECHANGING)
UNSUPPORTED_MSG(WM_STYLECHANGED)
/* UNSUPPORTED_MSG(WM_UNICHAR) FIXME missing in Wine headers */
@@ -1844,6 +1843,27 @@ LRESULT WINAPI RichEditANSIWndProc(HWND
return 0;
}
+ case WM_SETFONT:
+ {
+LOGFONTW lf;
+CHARFORMAT2W fmt;
+HDC hDC;
+BOOL bRepaint = LOWORD(lParam);
+
+if (!wParam)
+ wParam = (WPARAM)GetStockObject(DEFAULT_GUI_FONT);
+GetObjectW((HGDIOBJ)wParam, sizeof(LOGFONTW), lf);
+hDC = GetDC(hWnd);
+ME_CharFormatFromLogFont(hDC, lf, fmt);
+ReleaseDC(hWnd, hDC);
+ME_SetCharFormat(editor, 0, ME_GetTextLength(editor), fmt);
+ME_SetDefaultCharFormat(editor, fmt);
+
+ME_CommitUndo(editor);
+if (bRepaint)
+ ME_UpdateRepaint(editor);
+return 0;
+ }
case WM_SETTEXT:
{
ME_InternalDeleteText(editor, 0, ME_GetTextLength(editor));
diff --git a/dlls/riched20/editor.h b/dlls/riched20/editor.h
old mode 100644
new mode 100755
index 33b7626..a4d4980
--- a/dlls/riched20/editor.h
+++ b/dlls/riched20/editor.h
@@ -55,6 +55,7 @@ void ME_CopyToCF2W(CHARFORMAT2W *to, CHA
CHARFORMAT2W *ME_ToCFAny(CHARFORMAT2W *to, CHARFORMAT2W *from);
void ME_CopyToCFAny(CHARFORMAT2W *to, CHARFORMAT2W *from);
void ME_CopyCharFormat(CHARFORMAT2W *pDest, CHARFORMAT2W *pSrc); /* only works
with 2W structs */
+void ME_CharFormatFromLogFont(HDC hDC, LOGFONTW *lf, CHARFORMAT2W *fmt); /*
ditto */
/* list.c */
void ME_InsertBefore(ME_DisplayItem *diWhere, ME_DisplayItem *diWhat);
diff --git a/dlls/riched20/style.c b/dlls/riched20/style.c
old mode 100644
new mode 100755
index f420f09..6104a0c
--- a/dlls/riched20/style.c
+++ b/dlls/riched20/style.c
@@ -286,6 +286,25 @@ ME_LogFontFromStyle(HDC hDC, LOGFONTW *l
lf-lfCharSet = s-fmt.bCharSet;
}
+void ME_CharFormatFromLogFont(HDC hDC, LOGFONTW *lf, CHARFORMAT2W *fmt)
+{
+ int rx, ry;
+
+ ME_InitCharFormat2W(fmt);
+ rx = GetDeviceCaps(hDC, LOGPIXELSX);
+ ry = GetDeviceCaps(hDC, LOGPIXELSY);
+ lstrcpyW(fmt-szFaceName, lf-lfFaceName);
+ fmt-dwEffects = 0;
+ fmt-dwMask =
CFM_WEIGHT|CFM_BOLD|CFM_ITALIC|CFM_UNDERLINE|CFM_STRIKEOUT|CFM_SIZE|CFM_FACE|CFM_CHARSET;
+ fmt-wWeight = lf-lfWeight;
+ fmt-yHeight = -lf-lfHeight*1440/ry;
+ if (lf-lfWeight400) fmt-dwEffects |= CFM_BOLD;
+ if (lf-lfItalic) fmt-dwEffects |= CFM_ITALIC;
+ if (lf-lfUnderline) fmt-dwEffects |= CFM_UNDERLINE;
+ if (lf-lfStrikeOut) fmt-dwEffects |= CFM_STRIKEOUT;
+ fmt-bPitchAndFamily = lf-lfPitchAndFamily;
+ fmt-bCharSet = lf-lfCharSet;
+}
BOOL ME_IsFontEqual(LOGFONTW *p1, LOGFONTW *p2)
{
From 9ab4884c58a4de506ca43c761b1d55769dfc0614 Mon Sep 17 00:00:00 2001
From: Matthew Finnicum [EMAIL PROTECTED]
Date: Sat, 24 Jun
Re: How are we doing?
From the viewpoint of a new developer (Summer of Code), having a few The purpose of this function comments would have been / still would be very useful! It's painfully having to figure out what exactly a function does, that calls five other functions that you have to look into, which each call another cryptically named function. Also, sometimes it's not obvious why a function is called. A comment like Call funcResetStatusVariables because the above code triggers a redraw which can break them would save a new developer twenty minutes of But why update them THERE?! Does my code have to do that?. --Matt
Re: How are we doing?
I will be working on riched20 for SoC - Initially I'll be working on some unimplemented messages and styles, and then I'll be working on some of the missing COM interfaces. Details are at http://wiki.winehq.org/MatthewFinnicum --Matt On 6/1/06, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Any status on what projects have been approved and who is going to work on which project for this years SoC.
Re: Starred Chats ... blah blah blah
This was *supposed* to have been titled: riched20: Implement EM_SETUNDOLIMIT and its conformance tests, take 3 Sorry! --Matt On 5/15/06, Matt Finnicum [EMAIL PROTECTED] wrote: Hello! Patch updated w/ Dimi Paun's advice (using #define's for the default and max values), and slightly cleaned up. Thanks, --Matthew Finnicum Changelog: riched20: Implemented conformance tests for EM_SETUNDOLIMIT() riched20: Implemented EM_SETUNDOLIMIT() editor.c | 21 +++--- editstr.h |4 ++- tests/editor.c | 65 + undo.c | 27 ++- 4 files changed, 112 insertions(+), 5 deletions(-)
Re: README: Updated to not point users at wineinstall and to mention fontforge
On 4/10/06, Phil Krylov [EMAIL PROTECTED] wrote: On Mon, 10 Apr 2006 04:43:59 -0400Segin [EMAIL PROTECTED] wrote: Add these lines for those people that ask us how to use ~ARCH fontforge instead of RTFMing: To enable ~ARCH fontforge without setting your whole system ~ARCH, do this (as root): echo =media-gfx/fontforge-20060406 /etc/portage/package.keywordsIs this really preferable to the following? echo media-gfx/fontforge ~x86 /etc/portage/package.keywords-- Ph.Wine only needs version 20060406, so why set it to always pull them from ~ARCH? Someone who wanted to do that would likely be in ~ARCH anyways.Unless there's a reason to use other ~ARCH versions than 20060406, there's no reason for someone not in ~ARCH to get them (until they're moved out of ~). --Murph
Re: whats wrong with the wine devel list
Gmail also:To: wine-develjust does any domain.On 4/2/06, n0dalus [EMAIL PROTECTED] wrote:On 4/3/06, Joao Inacio [EMAIL PROTECTED] wrote: I use GMail, and i can filter by subject or by to: header... but not cc:... some emails get filtered, and some don't so i need to keep sorting them. In my gmail I am only filtering by to. I think to works for cc aswell. The problem might be that some users for some strange reasonsend list mail to winehq.com instead of winehq.org -- like now we areall replying to a subthread Duane started by sending one towinehq.com. So in my filter I have:To:(wine-devel@winehq.com OR wine-devel@winehq.org)
Re: file.c:246: Test failed: shouldn't be able to delete a readonly file
I'm at a windows XP machine right now. I have no trouble deleting read-only files - I get the dialog informing me it's read-only, but then it allows me to delete it.Is it the same on 95/98?--MurphOn 3/23/06, Huw D M Davies [EMAIL PROTECTED] wrote: On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote: Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it.If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed... Well the test passes on Win 2000.C:\kernel32_crosstest.exe filefile: 494243 test executed, 0 marked as todo, 0 failures.Huw.--Huw Davies [EMAIL PROTECTED]
