Krzysztof Foltman wrote:
Mike McCormack wrote:
...
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.
Perhaps a suggestion.
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 inter
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.
Whether you show us or not, the copyright for the source still belongs
to you.
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 encod
Krzysztof Foltman wrote:
- MBCS support (and it would be very hard to add)
Then you are doing something very wrong. Aren't you working in Unicode?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
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
James Hawkins wrote:
I just want to make sure I've got this right. So we need to implement
riched20, and then forward requests from riched32 to riched20 because
riched20 supercedes riched32?
Right. The current implementation of riched32 is Wrong(tm).
We'll implement riched20 from scratch and do it
I just want to make sure I've got this right. So we need to implement
riched20, and then forward requests from riched32 to riched20 because
riched20 supercedes riched32?
On Sat, 20 Nov 2004 11:46:12 +0900, Mike McCormack <[EMAIL PROTECTED]> wrote:
>
> James Hawkins wrote:
> >>which is why this
James Hawkins wrote:
which is why this code is not in WineHQ.
What is it exactly that is keeping this code out of wine? Just
curious because if it's something that just needs to be worked on, we
should let developers know so we can get started on that.
Like most things that are in CrossOve
James Hawkins wrote:
which is why this code is not in WineHQ.
What is it exactly that is keeping this code out of wine? Just
curious because if it's something that just needs to be worked on, we
should let developers know so we can get started on that.
The current riched32 is wrong. It should no
> which is why this code is not in WineHQ.
What is it exactly that is keeping this code out of wine? Just
curious because if it's something that just needs to be worked on, we
should let developers know so we can get started on that.
On Sat, 20 Nov 2004 10:16:39 +0900, Mike McCormack <[EMAIL PR
Hi Michael,
This isn't quite clear to me. It sounds like you are saying there is a
riched20.dll in wine, but I can't find one.
No, there's no riched20.dll implementation in Wine as yet.
> Are these statements correct?
* Wine's only implements RichEdit10A via riched32.dll. Wine does not
implement R
--- Michael Ost <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-11-19 at 03:22, Mike McCormack wrote:
> > Michael Ost wrote:
> >
> > > (1) The wine bug (I think) is that riched32.dll is registering the wrong
> > > window class name. Here's a suggested patch:
> >
> > RICHEDIT_CLASS20A is provided by r
On Fri, 2004-11-19 at 03:22, Mike McCormack wrote:
> Michael Ost wrote:
>
> > (1) The wine bug (I think) is that riched32.dll is registering the wrong
> > window class name. Here's a suggested patch:
>
> RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The
> windows 2000 impleme
Michael Ost wrote:
(1) The wine bug (I think) is that riched32.dll is registering the wrong
window class name. Here's a suggested patch:
RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The
windows 2000 implementation uses riched20.dll to implement riched32.dll
(ie. moves the ri
I'm re'ing my own post, but I think there's a combination of (1) a wine
bug and (2) user error at work here.
(1) The wine bug (I think) is that riched32.dll is registering the wrong
window class name. Here's a suggested patch:
[EMAIL PROTECTED] dlls]# diff -Naur richedit/richedit.c
richedit.MUSE/
Hi.
My winelib application can't create a window of class RichEdit20A. It
looks like the class is not being registered, because the DLL is not
being loaded. Any clues why this might be?
Turning on trace+richedit shows that dlls/richedit/richedit.c's
RICHED32_Register and DllMain are not being cal
17 matches
Mail list logo
