Re: segfaults with last selection repaint patch in riched20
Phil Krylov wrote: I was getting a segfault in ME_MarkForPainting() after that patch (BTW great work), Owww... I really hoped to avoid bugs in THAT :) and started looking through the code. One thing I found was obviously a typo which can be easily fixed (BTW I don't know for sure but I'd also update pLastSelStartPara and pLastSelEndPara here): Yes, it's a copy-paste bug. I thought I've fixed that one, but I obviously didn't. Updating pLastSelStartPara / pLastSelEndPara is not necessary, because any time a paragraph is deleted, those two variables are updated at para.c:257. But it did not resolve my problem. I did not have time to find the real reason for the segfault, but here is a quick hack which made the segfault go away and can probably help you in finding the real reason. What are the circumstances? Is it after some delete/insert operation, or just after document load? I'd do an assert(pLastSelStartPara-member.para.nCharOfs = pLastSelEndPara-member.para.nCharOfs) or something. That could possibly shed some light on the issue. I'm going to spend some time on it, as soon as I get Wine running after doing git clone from scratch yesterday (my old repository got FUBAR and I couldn't do anything to get it to sync to master). This git thing is a piece of unreliable unintuitive crap. Krzysztof
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote:
I don't see how that can be if users report crashes immediately when installer
tries to show licence. Or when user tries to scroll text to the bottom so Next
button will become enabled.
It doesn't happen on my machine on installers I've tried (including the
infamous NSIS), so it's not because of lack of testing at all. In fact,
I still don't know why it happens on one machine and not another.
Anyway, the issue is not easy to solve, so I'd be grateful for any ideas
that may help in solving this important issue.
_TRY
{
call riched20
}
_EXCEPT(handler)
_ENDTRY
Seems like easy to me.
How does that solve the improper operation vs lack of bug reports issue?
Do we want to have buggy richedit forever?
Unless you put some mail sending code in the exception handler. But that
qualifies as spyware and shouldn't happen.
Krzysztof
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote: upset. Users will have their functioning installers and you will have your error reports. I will have my error reports? How exactly will I get them? Does average user (or Wine) send us err: error reports? If he/she usually had, this would be a non-issue, and asserts could be replaced with if (!condition) ERR(...). Krzysztof
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote: I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? Well, that's the good question. The thing is, those conditions should never happen, and if they do happen, then something is really wrong somewhere with the code and a crash may happen anyway. I think it's better to get an assertion failure early than a random crash when it's too late to diagnose anything. And one can always comment the asserts out. But there are valid reasons why those asserts should be avoided. It's just about short term vs long term benefits. Maybe an option to disable those asserts would be a good idea so that people who just need to get the job done aren't messed with - but then we don't get half the bug reports we get now. As for the enormous (or even insane) amount of asserts - there's no such thing ;) Those asserts are pretty paranoid-level - chances of any of them happening is really, really low - and that's totally different to my previous repaint patch which had one assertion I predicted may be risky (which proved something is wrong with repaint, so it kinda served the purpose). The good solution would be a decent regression test, but it seems to be pretty difficult and/or tedious (simulating real-life conditions for testing repainting is hard because of relative timing/order of window messages). For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Those asserts are relatively independent on text input, and more on user interaction with the editor, which, as I already said, is hard to simulate and test (that's why I'm kind of shifting responsibility to end users: I may do as much monkey tests as you want, still I may get into some ruts of usage pattern). Anyway, the issue is not easy to solve, so I'd be grateful for any ideas that may help in solving this important issue. Krzysztof
VNC and worms
Can anyone figure out how to fix this display artifact that's very frequent when using Wine through VNC servers (tightvncserver and realvncserver, to be precise). http://foltman.com/worms.png It appears randomly on some redraws and not other ones (dragging the window off screen and back often makes the text look normal). Krzysztof
riched20 - patch ping
These could get in unchanged, perhaps? http://www.winehq.org/pipermail/wine-patches/2006-June/028096.html http://www.winehq.org/pipermail/wine-patches/2006-June/027940.html http://www.winehq.org/pipermail/wine-patches/2006-June/027978.html This is the one I want comments for before I split it into smaller parts (and update to take Thomas Kho's patch into account): http://www.winehq.org/pipermail/wine-patches/2006-June/028159.html Krzysztof
Re: Slow EULA display patch
Daniel Steven Hipschman wrote: This patch fixes the slow EULA loading problem in http://bugs.winehq.org/show_bug.cgi?id=5516 Well, *great* to see that solved in the Wine core, but I still think I have a bug in RichEdit, because the original (native) riched20 works fast, despite the bug you just fixed. Krzysztof
Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)
James Hawkins wrote: I've just looked at this patch and the previous patch Thomas sent in, and saying that this is roughly based on his patch is putting it lightly. The EM_GETLINE code is completely changed (I haven't even seen his new implementation - http://www.winehq.org/pipermail/wine-patches/2006-June/028096.html - before sending the patch in, and the old one was the one Alexandre wrote it needed fixing). Actually knowing about that patch would save me an hour or so of unnecessary work. The testing code is by Thomas and is completely unchanged, too. Yes, I should have emphasized that in the change log. But it wasn't meant to rip him off. I see that you've added the 1.0 emulation change, but that doesn't warrant you putting your name on his patch. I guess, let him decide about that. then add your code in a new patch, or to make him aware of the problems in his implementation, The fact is: - he sent the original patch long time ago, and he didn't fix the problems until very recently (because Alexandre only told us about the problem after I reminded him about his patch?) - the mail from Alexandre about the patch being wrong was explicitly addressed to me, so with lack of reaction from Thomas I assumed I should update the patch - my cleanup was created *independently* from the new (see above) patch from Thomas, and I'm not even sure which version I like more (the new version from Thomas is more compact, and multiplying nCopy by current character size may not be as patch-reject-prone as I initially thought, given Alexandre's stance about nBPC trick) - the cleanup involved removing lots of the original code and replacing it by my own (only in EM_GETLINE handler, not in the test code) - just compare the old vs my version; that's why I decided to add roughly - I think I have enough of genuinely mine and rather complex code in riched20 (like initial versions of style management, display, wrapper) to not be suspected of wanting to take credit for a loop doing (essentially) strcat and p=p-next, that I didn't code from scratch, at cost of Thomas :) missing feature, but either way, he deserves credit for the code he wrote, and not just saying that your code was based off of his. He obviously does. The previous version of the patch (which I re-sent) HAS his name as the sole author of the changes. Krzysztof
Re: riched20: corrected EM_GETLINE and wrong hWnd patches (combined into one)
James Hawkins wrote: this problem. The previous version you sent in did have his name, which is perfectly legit, but this version doesn't. You can either add his name as well as yours to the changelog, or ask him to resend the tests separately. So, the current plan is to: - See if the new Thomas patch gets accepted during the nearest 2 weeks - If yes, rewrite the 1.0 fix and it send separately - it's totally incompatible with that patch - If not, resubmit the EM_GETLINE stuff, with proper credits this time, maybe as two separate patches (implementation and unit test) - Move EM_LINELENGTH fix and editor pointer check into separate patches (as soon as they're OK so I don't have to split them over and over) Does that sound reasonable? Krzysztof
Re: riched20: WM_SETFONT support
Matt Finnicum wrote: 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. That'd be nice - as I mostly stopped doing riched20 stuff for quite some time, and only got back to it a few days ago. 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). 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. 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. 2) Your code ignores lParam (which is supposed to specify if it repaints immediately) It does not, it assigns it to bRepaint and then uses in a condition. So it's a correct solution. 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. 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. 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. 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. Krzysztof
Re: Wine project: Support third party LDDM graphic drivers
Stefan Dösinger wrote: Implementing a wrapper for windows graphics drivers is surely technically interesting, it's an unnecessary effort, which is better invested elsewhere(For example in making the native Linux drivers better). Haven't I heard something analogical before? That'd be... let's see... Wine myth.. #2? There will always be some obscure cards whose manufacturers just don't care about Linux. (-: Are you going to betray everyone that doesn't buy from Nvidia and ATI? :-) Krzysztof
Re: WINE Regression due to patch applied Feb 22, 2005 10:50 CDT
Mike McCormack wrote: I tried installing KeyNote, and it seems to have a richedit problem... it crashes in EM_GETTEXTRANGE around line 1579 in editor.c... making the allocation at line 1573 bigger seems to solve that. Can you test it with the latest uncommitted patches applied? (particularly, the recent 1.0 emulation 1/3 patch - ME_GetTextW fix - seems to be relevant). The same patch has fixed a similar problem with heap corruption in a different application (Revelation Patch). Krzysztof
Re: WINE Regression due to patch applied Feb 22, 2005 10:50 CDT
The patch that changed these files is:
ChangeSet ID: 16245
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED] 2005/02/22 09:50:14
That patch isn't directly responsible for the bug, it has probably just
revealed it.
The bugfix will be sent as soon as the previous bugfixes are accepted.
It looks more or less like this:
Index: editor.c
===
RCS file: /home/wine/wine/dlls/riched20/editor.c,v
retrieving revision 1.59
diff -u -r1.59 editor.c
--- editor.c3 Oct 2005 18:45:39 - 1.59
+++ editor.c9 Oct 2005 15:00:34 -
@@ -2062,10 +2075,10 @@
if (item-member.run.nFlags MERF_ENDPARA)
{
- *buffer++ = '\r';
+ *buffer = '\r';
if (bCRLF)
{
-*buffer = '\n';
+*(++buffer) = '\n';
nWritten++;
}
assert(nLen == 1);
Check it out, it works for me.
Krzysztof
Re: RICHED20: debug and 1.0 emulation fixes
Krzysztof Foltman wrote: 6th try already... Sorry about spamming. My email account started bouncing mails with *permanent* errors, so I decided resending might have been a good idea. Apparently it wasn't. Krzysztof
Re: Unused function in regedit/treeview.c
If that function is supposed to be useful, then scream or re-add it later. Re-adding would be a good idea. I thought it will be useful for finding an item in the tree, but then managed to do the same without using it. --- Krzysztof
Re: Problem Resolve
Molle Bestefich wrote: If not, and that one's going away in two days, then it's probably not worth it.. Well, assuming that nobody cares about the hundreds of (potential) users put off during those two days :-) Isn't it possible to post a previous version or remove it completely? Is it lots of work, or something rather easy? (the question is genuine, I don't know anything about insides of Wine release process) Krzysztof
Re: riched20.dll asserts
Ulrich Czekalla wrote: Could you try the attached patch. I must admit I don't fully understand the underlying data structures but I think this patch fixes the problem. I'll take a look at that, but can anyone give another (simple) test case? Krzysztof
Re: MSN Messenger builtin progress
Maarten Lankhorst wrote: I'll try playing around a bit with CreateTextServices and see how far I will come, it seems to be tricky, I can't find any useful information about it. My opinion - forget it. It'd require a major rework of the RICHEDIT20 control. The function is related to the windowless API of the Rich Edit Control, which is very different to what we have done so far. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/RichEdit/WindowlessRichEditControls.asp I don't even know of a test application I could use to play with this interface. Krzysztof
Re: Bug 2904
Juan Lang wrote: Whether or not the patch Michael attached is the real fix, it should solve the immediate problem (the assert failure.) I think it's an appropriate solution for now. I'll get back to it soon, it's quite likely that the assertion itself is wrong (character strings which are 0 pixels wide make sense to me, I'm just not sure if the wrapping code is able to deal with them). Krzysztof
Re: Riched20: thanks + regression beta not shown
Tobias Burnus wrote: I suppose this is more addressed to Krzysztof... The readability could be even better if tab positions were supported :) True ;) But failing to write patches for Wine myself, I'll try not to ask too much. I'm currently working on complete tab support, and will post a patch next week. It already includes support for tab positions. Krzysztof
Re: Hints needed for riched20/scroll bug solving
Paul Vriens wrote: agreement appears. I know that nobody reads this ;-) but hey. When I click in the scrollbar (page down) the page goes down 1 page and the scrollbar changes. My newest patch (released 5 minutes ago, not in CVS yet) attempts to fix that - at least, it works for me. Try it and tell me if it works for you. Krzysztof
animate control regression
The current CVS version has a regression in the animate control, causing
a deadlock, most probably in WM_DESTROY handler, in the app I'm testing
Wine with.
trace:message:SPY_ExitMessage (0x10038) L{SysAnimate32} message
[0047] WM_WINDOWPOSCHANGED returned
trace:message:SPY_EnterMessage (0x10038) L{SysAnimate32} message
[0002] WM_DESTROY sent from self wp= lp=
err:ntdll:RtlpWaitForCriticalSection section 0x403a3cb8 ? wait timed
out in thread 0009, blocked by 000a, retrying (60 sec)
Reversing these two patches seems to fix the problem:
http://cvs.winehq.org/patch.py?id=16654
http://cvs.winehq.org/patch.py?id=16619
I don't know if patch 16654 has any effect on this problem - I don't
know this code well enough to reverse patches in random order.
Hope it isn't difficult to fix...
Krzysztof
Re: [bug2796] Richedit bug
Ann and Jason Edmeades wrote: WCHAR *p = ALLOC_N_OBJ(WCHAR, nLen+1); #define ALLOC_N_OBJ(type, count) (type *)HeapAlloc(me_heap, 0, count*sizeof(type)) That is so embarrasing! They teach this in the nursery school :/ By coincidence, I've spent at least half an hour today on finding the memory overwrite elsewhere, which turned out to be caused by the bug above. The buffer overrun comment refers to something else - I'm not sure if WideCharToMultiByte will produce single byte character string for ANSI codepages. If it produced a real multibyte string, it could exceed the buffer supplied by the application. Krzysztof
richedit patches by Phil Krylov
ChangeLog: Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. IMHO the patch can be applied without changes. The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. Added generator RTF destination handling. Added missing PFA_JUSTIFY definition to richedit.h. Thanks for the fixes, I really didn't know how to get rid of the \generator. Maybe it will help me figure out how to ignore the rest of the RTF junk that I can't use anyway (\pgdsctbl and others). Krzysztof
Re: richedit patches by Phil Krylov
Phil Krylov wrote: The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. Can you fix it ? Judging from your RTF writer code and your last name, you probably have more knowledge about Unicode and RTF than I have. Krzysztof
Re: wine/ misc/registry.c documentation/samples/config
Boaz Harrosh wrote: Well! Above logic just eliminated Wine my friends. If Native dlls and Registry is a set back on Free Wine development, than logic would follow that, running native Windows applications (Wine) is a set back/discouragement of Free SW development. I restrained myself from saying that many times before, but I guess it should be said: Crippling functionality to get more developers is a tactic guaranteed to backfire. Often the reason new developers get involved is that they need to make something run in Wine for a commercial entity, and Wine already does everything except some small parts that can be developed in a reasonable time. That's like hhctrl.ocx stub was born (which is just a stub, but at least it makes some applications run without the Microsoft DLL), and that's how I got inspired to start a RICHEDIT clone. Had it not run the application I needed with a minimal set of native dlls, I'd have never have motivation to look at the source code of Wine. Removing functionality, even half-baked one, turns those missing small parts into large parts, effectively making Wine useless for those developers-to-be. On the other hand, with enough interest, the half-baked functionality may get improved for reasons like better compatibility or the ability to use the application without Microsoft DLLs (which may be particularly important for people wanting to use Wine with custom applications, in a commercial setting). removing it is not a viable solution. It narrows down the use of Wine to the point of no choice, No alternatives, and no Half baked solutions. Ether it works or it doesn't. No choice, no alternatives, no half baked solutions, no ability to use Wine, no interest in helping the Wine team. Amen. Krzysztof
Re: %Fp printf format specifier
%p = pointer %Fp = far pointer? (as in segment:offset pointer in 16-bit Windows) Oh, right, so there most likely IS a difference between %p and %Fp, since %p will get shown as 0x12345678, whereas %Fp probably gets rendered as something like 0x1234:0x5678. Nope. There are no far pointers in 32-bit Windows. It's a legacy thing. Just like LPSTR is a long pointer to string - yet there is no such thing as 'long' pointer anymore. a) we DO need to handle the F modifier Sure. b) it is probably used to format a FAR pointer (0x1234:0x5678) Nope. There's no difference between %Fp and %p anymore (not in win32), just like there is no difference between, say, PWORD and LPWORD. c) it should NOT be confused in any way with the lower-case-only float type specifier Sure. Krzysztof
Re: %Fp printf format specifier
Dnia 02-03-2005, ro o godzinie 17:34 +0100, Uwe Bonnes napisa(a): uses a %Fp format spezifier. Running with native msvcrt, this seems to be the same as %p. However builtin msvcrt stumbles about the superfluous 'F. %p = pointer %Fp = far pointer? (as in segment:offset pointer in 16-bit Windows) Krzysztof
riched20 patch preview
I've finally managed to make my riched20 code usable (hardly) and compatible with Wine. It's probably not good enough to go to CVS, but, at least, it's something you can try out. Comments are welcome. It should work with all programs that load RICHED20.DLL directly. For programs that load RICHED32.DLL you need a native version of that DLL (which is a wrapper for RICHED20.DLL, providing compatibility with 1.0 version of the control, the most important thing it does is loading RICHED20.DLL, which registers 2.0 window classes). http://foltman.com/riched20.tar.gz http://foltman.com/richeditpatch.diff Note, that EM_STREAMIN and EM_STREAMOUT don't work, so if your program uses RTF to insert text to the control, it won't work ! WinXP WordPad doesn't work either, as it uses RICHEDIT50W window class (what I provide is RichEdit20W control, haven't tried to fake it's 5.0). Have fun! Krzysztof
Re: riched20 patch preview
Krzysztof Foltman wrote: WinXP WordPad doesn't work either, as it uses RICHEDIT50W window class (what I provide is RichEdit20W control, haven't tried to fake it's 5.0). I've checked it now. It crashes somewhere in wordpad code, in something involving string operations. I've though it might be related to missing implementation of OLE interfaces, but it isn't. I'm investigating the problem, but it's not of top priority. Krzysztof
vartest.c - major pain in the build process
Is there any reason for gcc 3.3.1 to spend several minutes on compiling dlls/oleaut32/tests/vartest.c ? I guess it can be explained by optimization stage going nuts on compiling long functions with many branches (contained in the macros), but there must be a way to speed this up. It's barely tolerable now, and upgrading gcc is not an option for everyone. Krzysztof
Re: vartest.c - major pain in the build process
Jakob Eriksson wrote: Also, that won't stop people from running winetest on linux, I'll bet $5 winetest.exe downloads from WRT will keep showing up. Yes. But should something that's useless for the majority of users and developers be enabled by default ? Looks like significant cost with little benefit. That said, maybe winetest should not build by default. That doesn't sound like a lot of fun. Sounds like a good idea. And, by the way, a configure switch to disable all the DirectX modules would be nice too. One doesn't need DirectX to run business software. Or to work on a non-multimedia control like RichEdit20 ;) Or, maybe, a switch to skip building particular DLLs. Krzysztof
Cygwin X11 server, notepad and message boxes
I'm trying to run notepad on WINE, with DISPLAY environment variable pointing to Cygwin (X Server 6.7.0.0-12) running on my Windows XP machine. It works rather OK-ish, but when I try to close Notepad, it gets stuck in GetMessageW function call after displaying a text changed, do you want to save ? dialog box: trace:msg:GetMessageW (1117) mask=007f, bits=, changed=, waiting 0009:Call kernel32.ReleaseThunkLock(406ce6f8) ret=409b79a3 0009:Ret kernel32.ReleaseThunkLock() retval= ret=409b79a3 0009:Call x11drv.MsgWaitForMultipleObjectsEx(0001,403893f4,,,) ret=409b79c7 0009:Call kernel32.WaitForMultipleObjectsEx(0001,403893f4,,,) ret=40ce1838 0009:Call ntdll.NtWaitForMultipleObjects(0001,406ce32c,,,) ret=404e8989 I guess the bug is not in notepad, but in Wine message handling, as it's not the only program, that freezes after displaying a dialog box. It doesn't happen when MessageBox is called from WM_KEYDOWN handler, but it DOES happen when MessageBox is called from WM_CLOSE handler, but only if WM_CLOSE was sent by system after clicking Close or presing Alt+F4, and not sent or posted by application itself. http://foltman.com/wintest-dlginclose.zip Any idea what it may be ? deadlock ? The version of Wine I'm using was grabbed a couple of hours ago from anonymous CVS. Krzysztof
CreateCaret resets caret position (while it shouldn't)
There seems to be a difference in functionality of CreateCaret between Windows (XP at least) and Wine. You can find a test program at: http://foltman.com/wintest-caret.zip Look at this code snippet: CreateCaret(hWnd, NULL, 0, 20); SetCaretPos(100,100); CreateCaret(hWnd, NULL, 10, 10); In Wine, the 2nd CreateCaret resets caret position to (0, 0). In Windows, caret position doesn't get reset - it's still positioned at (100, 100). Note that calling CreateCaret twice without DestroyCaret is not a bug (after MSDN): - - - - - cut - - - - - CreateCaret automatically destroys the previous caret shape, if any, regardless of the window that owns the caret. The caret is hidden until the application calls the ShowCaret function to make the caret visible. - - - - - cut - - - - - Is it easy to fix for anyone ? Krzysztof
WM_CREATE failure and SetScrollRange argument validation
I've noticed another two things where Wine and Windows XP differ: 1. SetScrollRange(hWnd, SB_VERT, 0, -1) does nothing in WinXP, and is equivalent to SetScrollRange(hWnd, SB_VERT, 0, 0) in Wine. I guess it's true for all kinds of invalid arguments. 2. In WinXP, returning -1 from WM_CREATE causes window creation to fail - the newly created window is automatically destroyed (which sends WM_DESTROY to the window). In Wine, WM_DESTROY is not sent (which prevents the example program to finish). The short piece of relevant code can be downloaded from: http://foltman.com/wintest-scroll.zip Krzysztof
RICHEDIT again
It seems that I already have something useful. I've added multilevel undo/redo, GetCharFormat/SetCharFormat (very incomplete) and modify flag, and cleaned up the code a lot. The source code is downloadable from here: http://foltman.com/richtext-20050204.tar.gz I'll try to add handlers for basic editing messages (like WM_SETTEXT) and maybe notifications too, DLLize it and then make a Wine patch out of it. Is that OK ? It's not like everything is done the way it should be (for instance, coordinate system is still pixel-based and not twips-based), but in this stage the risk of having to constantly rewrite everyone else's code is much lower. Krzysztof
RICHEDIT once again
My rich text control is still far from even semi-complete, but I think too much is done to start over, so I'm releasing it today. The number one reason of its incompleteness is that I put more emphasis on making things work exactly like in the original than on implementing more functions. It's been neglected for weeks, and only recently I've fixed some old bugs and slowly started implementing the simplest parts of the RICHEDIT control API. I'm still not done with the basic stuff, like undo stack, so there is not much to hack on. On the other hand, it's likely I've made some bad decisions during design, and having someone experienced to look at that seemed to be a good idea to me. Some things look really tricky to implement with the current architecture, like the printing API (it will likely be an ugly hack, but I expect the same from the original, as screen formatting and print formatting may be very different). Some things just need time. I will probably need others' help to do the RTF parser. It's just way too much work. So, if anyone cares: http://foltman.com/richtext-20050130.tar.gz Compile using the recent-ish mingw (plus original SDK richedit header file). Have fun, Krzysztof
Re: RICHEDIT once again
Mike McCormack wrote: but I think the way forward is to submit an implementation of dlls/riched20 then make that work, and after it's debugged and worked out, rip out the old dlls/riched32 code and forward it to the new completed riched20 code. I'd prefer to keep it as an app, not a DLL for a while. It just makes testing easier. You've writen the code to deal with unicode as default, which is good, but you need to deal with both ASCII and unicode messages in the window procedure. Sure. And I guess it should be done before making a DLL out of it. It might be better to use libwineunicode and kernel32 unicode string manipulation functions rather than msvcrt ones. eg lstrlenW, lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type in Wine code. Good point. I guess it would be nice to replace malloc/free with LocalAlloc/LocalFree, right ? Similarly, you'll need to use winbase.h and friends instead of windows.h. Good idea. Done. From what I can see in the old riched32 code, the rtf parser looks quite good, so don't try rewrite that I'm all for reusing existing Wine code. haven't). We can merge the parser into the riched20 code quite easily... it's just enters the text into the existing control using EM_SETSEL and some formatting messages. LOL :) That's a smart idea :) I'm curious about interactions with undo, but we have no undo anyway (yet). I have a test I can send to you if you wish. You mean, another container application ? That would be cool, my container is getting better but it's still not very good. Again, my preference is to get this into the Wine CVS sooner rather than later, so others can start helping improve it. I'll see what can be done. As soon as there is a minimal text manipulation API (based on RichEdit API, not on function calls), I can separate the control into a DLL and move the app code in the test directory. So far, the next version is available at: http://foltman.com/richtext-20050130b.tar.gz Main changes are: - editor.c contains a list of which messages/notifications/styles work and which don't - incomplete read-only mode - replacement of MSVCRT wcs functions with Win32 lstr - a modification flag - a shy attempt at starting undo - a #define to choose between my editor and the original RICHEDIT. It's not what I want it to be, but it's better than nothing.
Re: RICHEDIT once again
Rob Shearman wrote: No, the LocalAlloc/LocalFree/GlobalAlloc/GlobalFree functions are relics from the old days of Win16. You should use HeapAlloc/HeapFree. True. Undo should be pretty easy as long as you can represent easily represent user actions in a transactions stack. Yes, I know the undo basics. The most recent source has the basic stack structure. :) It's still a bit complex, as, first, we have formatting to store on the stack (linked actions are the way to go), and it's easy to miss something, making undo fail in unusual circumstances. stack (although you would probably want some coalescing so that you don't have to undo each character you typed, There's more: it's required by RICHEDIT API. sentence). The undo command will pop a transaction of the stack and apply the inverse. Well, it can't apply the inverse ;) You need to push the inverse. However, there are a few superfluous typecasts. Any examples ? In particular, please remove the ALLOC_OBJ macro because the name seems to suggest it does more than it actually does. I'd prefer to rename the macro, and not remove it completely, it could be used for tracking memory allocations one day. And I don't really like the HeapAlloc API. This is just a suggestion and you may feel that it is easier to use your own. The big advantage is that it's independent from Wine-specific API. Which makes it more useful in non-Wine applications (the code is LGPLed, so why not use it somewhere else ?). A few more comments wouldn't go amiss either. Definitely. And to make things worse, not all FIXME's and XXXKF's are still relevant. It asks for a cleanup. But, undo first (because it involves even more major changes). What is the ParaStyle structure used for? Currently, it's not used. It's a placeholder for keeping real paragraph attributes, RICHEDIT's PARAFORMAT/PARAFORMAT2, part of which is currently stored directly in ME_Paragraph (nAlign, nLeftMargin, nRightMargin, nFirstMargin). The whole paragraph handling (para.c) needs lots of work. Each character can have a different style, so why is there a paragraph style? See above. The current content of the structure is irrelevant, and is a kind of legacy from my misunderstanding of the relationship between CHARFORMAT and PARAFORMAT. Krzysztof
Re: RICHEDIT once again
Rob Shearman wrote: What is the ParaStyle structure used for? How does this relate to the Style structure? Each character can have a different style, so why is there a paragraph style? Ahh, good news: the paragraph format structure (PARAFORMAT2) doesn't need any precalculation (contrary to the character style, which caches a HFONT and TEXTMETRIC). That means I can keep the paragraph format directly in the ME_Paragraph, and remove the ME_ParaStyle completely. In fact, I've just removed all the ParaStyle-related code without any negative consequences. Krzysztof
Re: RICHEDIT once again
Rob Shearman wrote: There are a few HGDIOBJ casts as well as the already mentioned ALLOC_OBJ macro. For example, in paint.c: DeleteObject((HGDIOBJ)hbr); Yes, both are HANDLEs, so they don't really need a cast. I've probably written too much MFC code in my life :) I've deleted all HGDIOBJ casts, but I'm not sure if it's the only case of redundant casts. Krzysztof
No RichEdit20A window class
Just for the record, I'm still trying to develop a proper RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think. If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at: http://foltman.com/riched.zip I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable. What IS done: - basic text wrapping with support for proportional fonts and character formatting, no major known bugs (the only supported attribute is Bold, but the rest will be relatively easy to add) - simple editing (typing text, backspace, delete, no overwrite mode yet) - a very incomplete implementation of Shift-arrow selection (done in a few hours yesterday :-) ), mouse operations don't support selection yet - per-paragraph alignment - pitiful low-level style management - bold attribute - some basic optimizations (avoiding rewrapping unmodified paragraphs unless editor window is resized) - uses UNICODE internally (not necessarily a good thing) What isn't done: - RichEdit API (which is a mess; I'm taking care of it in order to ensure compatibility wrt how editing functions work, however, basic editing functionality is the number one priority, as it's more difficult to achieve) - RTF interface - Undo - Clipboard - tabs - bulleted lists - setting paragraph attributes (margins are implemented internally but can't be changed with current interface, setting alignment by Ctrl+L/E/R works) - all RichEdit f3 functionality - MBCS support (and it would be very hard to add) - BiDi and CTL support (ditto) - everything not mentioned in the first list Krzysztof
Re: No RichEdit20A window class
Shachar Shemesh wrote: - MBCS support (and it would be very hard to add) Then you are doing something very wrong. Aren't you working in Unicode? I am. However, I've assumed that one character = one wchar_t, and there are no prefix/suffix non-printable characters. However, I'm speaking about encodings where character size may vary depending on a character. Like using utf-8 internally. All string operations (even benign ones like calculating number of characters) become much more complex, instead of O(1) mapping between character index (in characters) and character offset (in bytes or words), we have O(N). Chris
Re: No RichEdit20A window class
Mike McCormack wrote: I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq that others can help work on it. I'm quite interested to see the source for this. I may send the source code to people who are potentially interested, so that it may get taken over if I get very busy or bored of it, and so they can make up their minds about if the design and the actual code is good enough for WINE. Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later, I think I'll dual license it (LGPL/BSD). I can think of some closed source applications (freeware or not) that would definitely benefit from a free rich text editor that doesn't suck as much as RICHEDIT20 does. However, straight LGPL would be OK too, if BSD puts anybody off. so long as you are the sole author. That's where part of the problem is: as long as someone sends me just a Ctrl-arrow patch, I can always be suspected of stealing that patch. It puts me in a very uncomfortable position. release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features. I'm not going to wait until it's finished, I just don't want people to add features that must be removed or rewritten a week later because of half of functions have their parameters changed. For example, adding Undo functionality from scratch after everything else is done would be a disaster. When you do release your completed riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code. Another reason not to accept patches just now. Luckily, a commercial version (made for particular use in two or three applications of a particular company) will be actually very simple, having little more features than it has now, and no RICHEDIT API at all. After that, I may safely fork the source. Frankly speaking, people promising to release their source code at a later date is an impedement to development, because nobody is motivated to work on the promised feature in the mean time. That's what I'm afraid of, too. I'm currently thinking of solutions for that problem. Please consider release early, release often, so we can work together on this :) I agree, this project has a lot of space for collaboration. For example, achieving high degree of compatibility with RICHEDIT will require a lot of reverse engineering and finetuning. However, doing advanced features with basic architecture screwed up is not going to work. Krzysztof
Re: Directx9
Lionel Ulmer wrote: Well, if you are ready to pay the price of stability (i.e. spend at least 4 or 5 hours a week re-installing your 4 or 5 favourite applications to test for regression), fine :-) The problem I see is that we do not have the developper manpower to do that. However, it would be nice if regressions wrt particular programs were detected, pinned down to particular patches and *reported* by people who are particularly interested in making those programs work. For example, people who support WINE installations for their employers or customers. Other people who are supporting the same applications could benefit from that, because they'd know which patches should be removed or fixed. I've noticed some people already do that, but if the practice described above was more widespread, we could end up with fewer regressions, easier support and (usually) less work for developers. Chris
WinInet and doubtful assertion in FTP_Connect
For some reason, FTP connections in WININET crash on assertion: assert( hIC-hdr.htype != WH_HINIT ); However, it seems the assertion is either wrong, or confusing (if its intention was to point out that FTP code is unimplemented). FTP_Connect is called from two places, InternetConnectW and InternetOpenUrlW. As for InternetConnectW, it won't call FTP_Connect unless htype is set to WH_HINIT. As for InternetOpenUrlW, I'm not sure what htype does it expect. However, it's supposed to use HINTERNET handles coming out of InternetOpen, which sets htype to WH_HINIT. After changing != to ==, InternetConnect works (to a degree). Don't know about InternetOpenUrl, but theoretically it should too. Chris
Re: Richedit control
Mike McCormack wrote: I'm going to play with the richedit control to try get it to draw RTF documents with formatting. I've started the richedit thing long ago, and now I have some working text wrapping code ready. So far it can use different fonts and attributes (with row height adapting to largest font in the row, words can consist of characters of different font), omit spaces beyond right margin, align paragraphs to left/right/center (no justify, but original richedit doesn't have that either), can display the caret in proper place (but only move left/right/home/end) and use different wrapping strategies depending on available width. As the company I work for is interested in licensing it from me, I could double license it to be used both in Wine and the proprietary application (which wouldn't like the rocksucking API and horrible limitations of the original RichEdit). Of course, that doesn't make sense when somebody has much more code, waiting for me to finish a basic implementation for others to hack on would be just wasting time. Chris
Re: RegEdit problems
Dimitrie O. Paun wrote: I was working on it a bit, but I got sidetracked. I have a patch in the tree for a while now, but I haven't had time to clean it up and submit. Well, I can try to clean the patch up for you, I guess it could save me a lot of work anyway. Krzysztof
RegEdit problems
During deployment of some Linux desktop setup I had a major problem with WINE's regedit. First, I don't seem to be able to edit the (default) values of the keys (if they don't exist already ?). Second, the Modify dialog has Cancel as its default button. Third, there is no Find function. There are also some weird error messages in unexpected places. Is anybody working on it, or should I try it ? Using native regedit is not an option, as our goal is to avoid being a BSA victim completely. Krzysztof (who can't continue the RichEdit before getting the damn desktop to work)
Re: MDI fix attempt
Dmitry Timoshkov wrote: The patch I just sent to wine-patches should fix that problem. It fixed the problem, both with my sample and with the app that I couldn't use because of the bug. Thanks. Krzysztof
Re: MDI fix attempt
Dmitry Timoshkov wrote: Is there a real bug you are trying to fix? Yes. Some accounting app that works perfectly under Windows, has its menu cut off at the last separator. Because the part which is cut off contains some essential functions (like creating a new database), I'd classify as a bug. And as the patch fixes makes it run as under Windows I'd classify as a fix. Good fix ? I don't know. The app uses the Window menu in a very untypical way (it's not called Window, and most of the menu isn't related to window operations, the only Window menu functionality used is the window list). I wouldn't call it standards-compliant, but it works under Windows and there's no reason why it shouldn't work in WINE. When I last time worked with MDI code including Window menu handling I did a lot of tests under Windows. Did you? I did some (especially under Windows, where it's easier to find an MDI application that works). However, I wouldn't call that a lot of tests. That's why I've asked for help here. Krzysztof
Re: MDI fix attempt
Dmitry Timoshkov wrote: Then perhaps you have a +relay trace which exposes a problem and could write a simple test app based on that information? http://foltman.com/mdi/ Run it on Windows (I've tested in under XP), run it under original WINE, run it under WINE+my patch. Compare the Window menus with 0, 1 and 2 child items. It's supposed to have two dummy items (Dummy option 1 and Dummy option 2), as well as normal child window list (with separator if any child exists, with no separator if there are no children). Under original WINE (mdi.c from the latest CVS, the rest is one or two days old), the Dummy option 2 mysteriously disappears. Just try to create a child window and look at the Window menu. And BTW, my app is silly and badly written. I've compiled it with mingw, as I don't have VC++ at home. I hope noone cares. Krzysztof
RFH: MDI Window menu fix
I've just finished fixing the behaviour of Window menu in MDI applications. However, I'm not sure if it won't cause some other MDI applications to work incorrectly. So, if you have some time and MDI apps to play with (regardless if they worked correctly before or not), check this out and tell me if I've fixed or broken the Window menu. http://www.winehq.org/hypermail/wine-patches/2004/04/0414.html Krzysztof
richedit - anybody trying to do it ?
Hi, Just out of curiosity: is anyone already actively developing a (supposedly) fully featured richedit control ? The current version looks like a plain editor combined with RTF reader... -- Chris
Re: DateTimeCtrl doesn't select a new date
Felipe W Damasio (Elipse Software) wrote: My recent patch seems to fix that, as well as some other issues: http://www.winehq.org/hypermail/wine-patches/2004/04/0320.html Fixed it indeed. Nice to hear that :-) PS: Did your patch got applied on mainline wine? I didn't find any response to your post on wine-patches. Not yet. I hope it gets reviewed soon, but it seems Dimitrie is busy with winetest right now. Krzysztof
Re: DateTimeCtrl doesn't select a new date
Felipe W Damasio (Elipse Software) wrote: Whe using CDateTimeCtrl and selecting a new date on that calendar thing, the date isn't selected and the widnow isn't closed. My recent patch seems to fix that, as well as some other issues: http://www.winehq.org/hypermail/wine-patches/2004/04/0320.html Krzysztof
