January 2002 - Wine-Devel - list.winehq.org

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Can you suggest how to implement these switches - as > command-line arguments or environment variables? Environment variables are better. I did that already in the perl framework, look at the runtest script for the variables I'm using. You probably want to do things the same way so that it's easier to mix Perl and C tests. I don't have a die on failure flag though, but I don't think this is really necessary. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2002

Re: What are you really aiming to do with winetest?

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > It would be nice if you commented on what you > think about my spec2pm script for automatically > generating Perl modules for calling the Windows API. Sure; I was looking into integrating it, but found some problems. I agree generating modules automatically is a good idea; the main problem right now is that we cannot get the return type of the functions, and this breaks functions returning a string. > Also, I'm not sure that you are trying to do: > The files generated by make_symbols are quite useless, > they just contain a lot of LOCAL variables. They seem to work just fine for me, but I'm no Perl expert, so if you think your approach is better I'll do it that way. -- Alexandre Julliard julliard(a)winehq.com

Jan. 15, 2002

Sponsoring by IBM, lets get it done

by Roland

Hello, to put an end to this discussion, I will start trying to contact people at IBM for sponsoring, unless someone more qualified wants to do it. Anyone? Ok, so where do I start, can someone give me an email adress? I also wanted to know some technical terms: 1. How do you call the person who is TECHNICALLY responsible for a project, in this case, for the Linux stuff at IBM? 2. How do you call the person who is FINANCIALLY responsible for a project, in this case, for the Linux stuff at IBM? If someone can provide the answer to 1 and 2, it would help, the email adress I will figure out myself...if no one can provide one... Thanks...Roland

Jan. 15, 2002

Re: fixme:richedit:RICHED32_WindowProc Unknown message 129

by Francois Gouget

On Tue, 15 Jan 2002 lawson_whitney(a)juno.com wrote: [...] > Hmmm, I can not get a +snoop=riched32 trace with the native > riched32. That frustrated me the last time I beat my head against this > app and riched32. +snoop simply hangs, and +edit,-snoop=msvcrt produces > a huge trace, but the only mention of riched is in some strings to > mfc42.6442. What happens when snoop hangs? Does the process seem to get into an infinite loop? I once had a problem with +snoop where it would get into an infinite loop when the pointer was 0xffffffff (-1). I did not have time to get to the bottom of this at the time and now I am not sure I can even reproduce the problem. But I did work around the problem by checking for -1 before doing the string check. See the attached patch. +snoop was looping where I added the TRACEs. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Jan. 15, 2002

Listview Unicodification (take 3) (fwd)

by Dimitrie O. Paun

[once again, I attached the patch by mistake, and the mail did not go through...oh well, that happens if you don't sleep at night:) ] Hi folks, Here is the latest version of the Unicode ListView control: http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff It fixes a silly (e.g. brown paper bag type of bug, really) pointed to me by Gerard (thanks!). It does fix a problem with the subitem handling (before, the subitems were simply ignored). Tested with the Common Control Spy Sample thingy from MS. I still could not get Gerard's examples going, and it seems I really need to test with those... If things look OK, I will forward it to Alexandre soon. -- Dimi.

Jan. 15, 2002

Re: fixme:richedit:RICHED32_WindowProc Unknown message 129

by lawson_whitney＠juno.com

On Tue, 15 Jan 2002, Daniel Walker wrote: > > > > fixme:richedit:RICHED32_WindowProc Unknown message 129 > > fixme:richedit:RICHED32_WindowProc Unknown message 528 > > fixme:richedit:RICHED32_WindowProc Unknown message 130 > > This patch will take out the fixme msgs , but I don't think it will fix > anything.. You will have to run your application with "--debugmsg > +edit,+richedit" to should show you any errors/msgs from the controls. > Let me know what happens .. > > Daniel Walker I didn't mean to complain about a few fixme's. Removing them doesn't help, of course, and I don't see anything that looks like an error in this. My guess is that the app expects the parent to do something on being notified. Hmmm, I can not get a +snoop=riched32 trace with the native riched32. That frustrated me the last time I beat my head against this app and riched32. +snoop simply hangs, and +edit,-snoop=msvcrt produces a huge trace, but the only mention of riched is in some strings to mfc42.6442. Well, maybe you can make some sense of it, and if not, where's the harm? Lawson

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Well, I thought about very simple test case like > this one (in C): [...] > If anybody could provide some hints how to integrate > it into the winetest > system, I and other people will certainly appreciate > it. Dmitry, I changed the your test to use the C testing framework I posted today. The test is attached. Alexandre, can we start to submit unit tests to CVS? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Andriy Palamarchuk

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Well, I thought about very simple test case like > this one (in C): [...] > If anybody could provide some hints how to integrate > it into the winetest > system, I and other people will certainly appreciate > it. Dmitry, I changed the your test to use the C testing framework I posted today. The test is attached. Alexandre, can we start to submit unit tests to CVS? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 15, 2002

Re: WSAAccept

by Martin Wilck

Dear Daniel, I seem to have problems sending mail directly to your address ... > No problem .. Although, Something is better than nothing .. I have an > application that uses this function, and I wanted that application to > work .. Even though my implementation is not complete, since it's now in > the main wine source it can mature .. By withholding your implementation > your not doing anyone any favors .. Yeah, that was my very first wine patch ever, and I didn't understand the rules of wine-devel & wine-patches by that time. Afterwards I forgot about it, concentrating on overlapped IO, and was reminded of it by your patch. It is good to see that we seem to be in basic agreement, though. After all, it will probably happen very rarely that an app rejects or even defers clients. Btw: will you be working on more Winsock stuff in the near future? If yes, I guess we should try to coordinate our efforts somehow. Cheers, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 15, 2002

Re: WSAAccept

by Daniel Walker

Martin Wilck wrote: > > Hi Daniel, > > I have some concerns wrt your WSAAccept implementation you sent to > wine-patches on Sunday. I have thought a bit about this function > (did you notice my preliminary implementation on Nov. 7 (subject > "[EXPERIMENTAL PATCH]: Winsock2" ?). I found it after I had submitted mine .. > The problem I see is related to the treatment of the peer when > the user-supplied condition function returns CF_REJECT or CF_DEFER. > > Your implementation calls WS_Accept _before_ calling the condition > function. That is, the peer will think its connection request was > accepted, and possibly start to send or poll for data. > Then if the Condition function returns CF_REJECT, the connection is > closed. When I was writing this function I didn't find a good way to get information on the connections before accepting() them .. > Even worse, for CF_DEFER, the peer receives nothing, the > new socket cs returned by WS_Accept remains open but is forgotten after > WSAAccept() returns (correct me if I'm wrong). > So the peer will think it's connected, > but no future WSAAccept or WS_Accept call will ever return a socket > connected to it, and it'll be sending data into the void. > > I think you must at least closesocket(cs) for CS_DEFER as well to avoid > this situation. Alternatively (that's the way I did it) the new socket can > be stored in the wineserver to be returned by future WSAAccept calls. > > The Winsock2 specs say that "[WSAAccept] extracts the first connection > on the queue of pending connections" (after a CF_DEFER, that should be the > previously deferred connection, until it's either accepted or rejected). > Moreover, it says that "[In the CF_DEFER case] no action about this > connection request should be taken by the service provider". > Taken seriously, this means that it's wrong to call accept() on this > request before a positive decision was made by the Condition function Point taken .. I realized this when I was looking at your patch a few days ago .. > Summarizing, the peer should see: > > CF_ACCEPT: his request is accepted (this case is OK). > CF_REJECT: his request is rejected (not ok, he receives an accept followed > by a close). > CF_DEFER: nothing (not OK, he receives an accept followed by ???) > > I have no idea how this affects behaviour of "real" applications. > > The essential problem is that there is no way (well, I have found none) > to obtain the peer's socket address on Linux without accept()ing first. > I guess that is what made you call accept() before the condition routine. > Perhaps someone can come up with a method to read the socket address > of a waiting connection request before it's accepted, but my guess is this > won't work without a kernel hack. Right. > At the very least, though, I consider it necessary to include a FIXME that > tells users that this function may behave different from what the specs > say. > > Please don't get me wrong, it's great to see other people work on Winsock, > and your code is clean. I just thought I need to express these concerns. No problem .. Although, Something is better than nothing .. I have an application that uses this function, and I wanted that application to work .. Even though my implementation is not complete, since it's now in the main wine source it can mature .. By withholding your implementation your not doing anyone any favors .. Daniel Walker

Jan. 15, 2002

Re: async_private + ReadFile() etc. immediate completion

by Martin Wilck

On Fri, 11 Jan 2002 lawson_whitney(a)juno.com wrote: > The app works with those patches, so the trace is much bigger. The app > also works with those patches, but without tracing (sometimes tracing > might change an app's behavior). That's great! If it works, actually noone needs the trace :-) This means the patch appears to work with both file and serial IO which have very different semantics and are the only two file types for which wine currently supports async IO. I'll rework the patch ASAP and resubmit it for wine-patches based on the current CVS. Thanks Lawson! Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 15, 2002

Re: fixme:richedit:RICHED32_WindowProc Unknown message 129

by Daniel Walker

lawson_whitney(a)juno.com wrote: > > Good day! > > Thanks, Daniel Walker, for your work on riched32. Your welcome .. > I don't know what or why is richedit and I'm kind of GUI-challenged, or > I'd have a go at implementing these myself, but I have an app that uses > it, so if traces would help, just say which traces and if you want them > for builtin or native riched32. The app fails with a bogus message box: > "Insufficient memory or disk space" after these three fixme's with the > builtin, so those traces should be pretty short, but maybe it would also > be useful to try to use spy on the native riched32. If spying on > msvcrt, mfc42, and/or the app's own dll's is likely to make noise, I can > filter it out, but at this point I don't know. > > fixme:richedit:RICHED32_WindowProc Unknown message 129 > fixme:richedit:RICHED32_WindowProc Unknown message 528 > fixme:richedit:RICHED32_WindowProc Unknown message 130 This patch will take out the fixme msgs , but I don't think it will fix anything.. You will have to run your application with "--debugmsg +edit,+richedit" to should show you any errors/msgs from the controls. Let me know what happens .. Daniel Walker Index: richedit.c =================================================================== RCS file: /home/wine/wine/dlls/richedit/richedit.c,v retrieving revision 1.15 diff -u -r1.15 richedit.c --- richedit.c 2002/01/14 19:44:07 1.15 +++ richedit.c 2002/01/15 13:56:49 @@ -98,6 +98,14 @@ switch (uMsg) { + case WM_NCCREATE : + DPRINTF_EDIT_MSG32("WM_NCCREATE"); + return 1; /* Return TRUE to continue creation. */ + + case WM_NCDESTROY: + DPRINTF_EDIT_MSG32("WM_NCDESTROY"); + return 0; + case WM_CREATE : DPRINTF_EDIT_MSG32("WM_CREATE"); @@ -507,6 +515,9 @@ return SendMessageA( hwndEdit, uMsg, wParam, lParam); /* Messages known , but ignored. */ + case WM_PARENTNOTIFY: + DPRINTF_EDIT_MSG32("WM_PARENTNOTIFY"); + return DefWindowProcA( hwnd,uMsg,wParam,lParam); case WM_NCPAINT: DPRINTF_EDIT_MSG32("WM_NCPAINT"); return DefWindowProcA( hwnd,uMsg,wParam,lParam);

Jan. 15, 2002

Re: WSAAccept

by Martin Wilck

Hi Daniel, I have some concerns wrt your WSAAccept implementation you sent to wine-patches on Sunday. I have thought a bit about this function (did you notice my preliminary implementation on Nov. 7 (subject "[EXPERIMENTAL PATCH]: Winsock2" ?). The problem I see is related to the treatment of the peer when the user-supplied condition function returns CF_REJECT or CF_DEFER. Your implementation calls WS_Accept _before_ calling the condition function. That is, the peer will think its connection request was accepted, and possibly start to send or poll for data. Then if the Condition function returns CF_REJECT, the connection is closed. Even worse, for CF_DEFER, the peer receives nothing, the new socket cs returned by WS_Accept remains open but is forgotten after WSAAccept() returns (correct me if I'm wrong). So the peer will think it's connected, but no future WSAAccept or WS_Accept call will ever return a socket connected to it, and it'll be sending data into the void. I think you must at least closesocket(cs) for CS_DEFER as well to avoid this situation. Alternatively (that's the way I did it) the new socket can be stored in the wineserver to be returned by future WSAAccept calls. The Winsock2 specs say that "[WSAAccept] extracts the first connection on the queue of pending connections" (after a CF_DEFER, that should be the previously deferred connection, until it's either accepted or rejected). Moreover, it says that "[In the CF_DEFER case] no action about this connection request should be taken by the service provider". Taken seriously, this means that it's wrong to call accept() on this request before a positive decision was made by the Condition function. Summarizing, the peer should see: CF_ACCEPT: his request is accepted (this case is OK). CF_REJECT: his request is rejected (not ok, he receives an accept followed by a close). CF_DEFER: nothing (not OK, he receives an accept followed by ???) I have no idea how this affects behaviour of "real" applications. The essential problem is that there is no way (well, I have found none) to obtain the peer's socket address on Linux without accept()ing first. I guess that is what made you call accept() before the condition routine. Perhaps someone can come up with a method to read the socket address of a waiting connection request before it's accepted, but my guess is this won't work without a kernel hack. At the very least, though, I consider it necessary to include a FIXME that tells users that this function may behave different from what the specs say. Please don't get me wrong, it's great to see other people work on Winsock, and your code is clean. I just thought I need to express these concerns. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 15, 2002

C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

Attached are new version of the C testing framework. Changed SystemParametersInfo unit test to use this framework. Alexandre, I need to use a couple switches for the test application: - output verbosity level - die on failure indicator Can you suggest how to implement these switches - as command-line arguments or environment variables? Using environment variables is easier for me - I don't need to do parsing of 2 types of command line (main and WinMain formats), no need to force test developers to use function like start_test( args ) in the beginning of their tests. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 15, 2002

Re: DPA_LoadStream

by Aric Stewart

True true, here instead of a constant i instead show how i came up with the number. This is also more portable if wine ever gets moved to a system with a larger UINT_MAX. -aric Uwe Bonnes wrote: > > >>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: > > Aric> + if (streamData.dwItems > 536870911) > > Shouldn't have such a magic number either a comment or better be defined as > a constant with some sensible name? > > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: dlls/comctl32/comctl32undoc.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/comctl32undoc.c,v retrieving revision 1.54 diff -u -u -r1.54 comctl32undoc.c --- dlls/comctl32/comctl32undoc.c 2002/01/14 18:36:03 1.54 +++ dlls/comctl32/comctl32undoc.c 2002/01/15 12:37:31 @@ -19,6 +19,7 @@ #include <string.h> #include <stdlib.h> /* atoi */ #include <ctype.h> +#include <limits.h> #include "commctrl.h" #include "objbase.h" @@ -108,6 +109,9 @@ streamData.dwData2 < 1) { errCode = E_FAIL; } + + if (streamData.dwItems > (UINT_MAX / 2 / sizeof(VOID*))) /* 536870911 */ + return E_OUTOFMEMORY; /* create the dpa */ hDpa = DPA_Create (streamData.dwItems);

Jan. 15, 2002

Re: Comctl32_419

by Uwe Bonnes

>>>>> "Huw" == Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: ... Huw> + * @ [COMCTL32.419] + * + * FIXME: What's this supposed to do? + What program on what version of WinXX uses that function? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 15, 2002

Re[2]: PATCH: Euro

by Nerijus Baliunas

On Sun, 6 Jan 2002 18:16:49 +0100 Patrik Stridvall <ps(a)leissner.se> wrote: PS> Does patches exists for all versions of Windows? PS> Including Windows 3.1 and Windows 95? Yes - http://www.microsoft.com/windows/euro.asp Regards, Nerijus

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > GetSystemDirectory seems easier then other filesystemn functions, as you > know exactly what to get. Other functions, like GetLongPathname has zillions > of possible combinations of dots, slashes and backslashes that complicates > things enormous. I think only by comparing test output produced with Wine > and Win32 we can see whether Wine behaves right. Exactly. Why just to not hardcode values retrieved from the running the test under Windows and compare them in the test run? To simplify things it should be possible to merge GetLongPathName with CreateFile and CreateDirectory in the single test case. That would give us completely predictable results. -- Dmitry.

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> If anybody could provide some hints how to integrate it into the Dmitry> winetest system, I and other people will certainly appreciate Dmitry> it. GetSystemDirectory seems easier then other filesystemn functions, as you know exactly what to get. Other functions, like GetLongPathname has zillions of possible combinations of dots, slashes and backslashes that complicates things enormous. I think only by comparing test output produced with Wine and Win32 we can see whether Wine behaves right. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 15, 2002

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Please let us know if you find some sensible way to test filesystem > functions. What I do now is > - export some filesystem tree with SMB(NCP) > - import it in Vmware with some drive letter > - use the same drive letter in the wine-config for the same filesystem tree > > I don't think this solution is very sensible for a more generalized test... Well, I thought about very simple test case like this one (in C): #include <assert.h> #include <string.h> #include <windows.h> int main(void) { UINT len, len_with_null; char buf[MAX_PATH]; strcpy(buf, "foo"); len_with_null = GetSystemDirectory(buf, 1); assert(strcmp(buf, "foo") == 0); strcpy(buf, "foo"); len = GetSystemDirectory(buf, len_with_null - 1); assert(len == len_with_null); strcpy(buf, "foo"); len = GetSystemDirectory(buf, len_with_null); assert(strcmp(buf, "foo") != 0); assert(len == strlen(buf)); assert(len == (len_with_null - 1)); return 0; } If anybody could provide some hints how to integrate it into the winetest system, I and other people will certainly appreciate it. -- Dmitry.

Jan. 15, 2002

Filesystem Regression Test, was: Re: RESEND: Fix return value ...

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello. Please use this patch instead of the previous one. I'll Dmitry> try to find some time and figure out how to write regression Dmitry> test for this functions. Please let us know if you find some sensible way to test filesystem functions. What I do now is - export some filesystem tree with SMB(NCP) - import it in Vmware with some drive letter - use the same drive letter in the wine-config for the same filesystem tree I don't think this solution is very sensible for a more generalized test... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 15, 2002

Re: DPA_LoadStream

by Uwe Bonnes

>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: Aric> + if (streamData.dwItems > 536870911) Shouldn't have such a magic number either a comment or better be defined as a constant with some sensible name? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 15, 2002

(no subject)

by Mike McCormack

Hi Sam, This list is for discussing development of Wine, not Windows NT applications. If you have a Windows binary that you want to run in Linux, then get back to us. If you're writing a program to run in Linux, then use termios to solve your problem. If you're writing a program for Windows NT, then your talking to the wrong people. Mike > Hi, > > I am currently trying to write a program to implement a communication > protocol using WIN32 APIs on Windows NT 4.0. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Jan. 15, 2002

Reading Line Status Register for Serial Communications on win32

by SAM .

Hi, I am currently trying to write a program to implement a communication protocol using WIN32 APIs on Windows NT 4.0. For this purpose it is required for me to read the parity bit of the Line Status Register when receiving data. The only way I could think of doing this was using by using IOCTL_SERIAL_LSRMST_INSERT code and enabling the LSRMST INSERT mode so that LSR information will be in the data stream read by ReadFile. Unfortunately for some reason this doesnt seem to work according to how it is documented. If anybody has used this function before can you please give me some tips as to what I might be doing wrong??? Also are there any other methods by which I can read the LSR on NT??? Thanks. Sam _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Jan. 15, 2002

fixme:richedit:RICHED32_WindowProc Unknown message 129

by lawson_whitney＠juno.com

Good day! Thanks, Daniel Walker, for your work on riched32. I don't know what or why is richedit and I'm kind of GUI-challenged, or I'd have a go at implementing these myself, but I have an app that uses it, so if traces would help, just say which traces and if you want them for builtin or native riched32. The app fails with a bogus message box: "Insufficient memory or disk space" after these three fixme's with the builtin, so those traces should be pretty short, but maybe it would also be useful to try to use spy on the native riched32. If spying on msvcrt, mfc42, and/or the app's own dll's is likely to make noise, I can filter it out, but at this point I don't know. fixme:richedit:RICHED32_WindowProc Unknown message 129 fixme:richedit:RICHED32_WindowProc Unknown message 528 fixme:richedit:RICHED32_WindowProc Unknown message 130 Regards, Lawson

Jan. 15, 2002