Ori Pessach [EMAIL PROTECTED] wrote:
Since this is probably not the case, perhaps it's better to check for the
popup menu class in is_window_managed(), something like
if (GetClassLongA(win-hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return
FALSE;
Ah ha! Exactly what I had in mind.
Andriy Palamarchuk [EMAIL PROTECTED] wrote:
One more important change in C framework is support of
Unicode in testing.
Dimitry, can you look at it? See how it is used in
sysparams.c, search for has_unicode function call.
I'm interested in your comments.
I would suggest to explicitly use A
Andriy Palamarchuk [EMAIL PROTECTED] wrote:
I mean real Windows 95. Tests should be compiled and
run on all the Windows platforms to insure their
correctness.
Is there a way to check whether given version of Win32
supports UNICODE?
Probably some tests should be marked as expected to fail
Uwe Bonnes [EMAIL PROTECTED] 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
Uwe Bonnes [EMAIL PROTECTED] 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
Andriy Palamarchuk [EMAIL PROTECTED] wrote:
Dmitry, I changed the your test to use the C testing
framework I posted today. The test is attached.
It looks good to me, but we should not forget to test both
unicode and ANSI versions of functions. There are two
approaches to accomplish this task:
Mark G. Adams [EMAIL PROTECTED] wrote:
Here's the message output on startup if those functions are not exported at
the expected ordinals:
err:win32:PE_fixup_imports No implementation for WINSPOOL.DRV.201 imported
from C:\OmniMark\EnterpriseStudio6_1_1\OmniMark-Enterprise-Studio.exe,
Mark G. Adams [EMAIL PROTECTED] wrote:
The fact that it worked with different functions there did surprise me. My
assumption (not having a good idea on how ordinal importing works) was that,
at this point, it's just checking for the presence of a function but not
executing it. Very little
Oliver Sampson [EMAIL PROTECTED] wrote:
Thanks! How does one know that it was this type of problem, as
opposed to another type of problem?
Well, just solve that type of problem at least twice...
--
Dmitry.
Michael Zayats [EMAIL PROTECTED] wrote:
I have a dll that is not thread safe (i.e. has many global variables, about
500). I have the sources for the dll.
The target is to make it thread safe.
Moving all the variables to thread specific storage is very complicated.
Making it thread safe on
Francois Gouget [EMAIL PROTECTED] wrote:
[...]
What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads
to differences in size of structures.
That's very strange. It would be good to understand why because this
should not happen.
Any ideas, why does it happen? Is it
Ulrich Weigand [EMAIL PROTECTED] wrote:
Without pshpack4.h sizeof(LUID_AND_ATTRIBUTES)=16 instead of 12. Don't ask
me why.
Because the size of a structure is always padded to the next multiple of
its alignment (so that in an array of structures, every element is properly
aligned iff
Francois Gouget [EMAIL PROTECTED] wrote:
Wine cannot use Unicode strings literals. When you write LYES this
is a 32bit Unicode string, not a 16bit unicode string. This means that
when you pass it to lstrcmpiW, which expects 16bit Unicode strings like
all the APIs in Wine, what it sees is
François Gouget [EMAIL PROTECTED] wrote:
- TRACE((%p %p %x)\n,pidl,szOut,uOutSize);
+ TRACE((%p %p %x)\n,pidl,debugstr_a(szOut),uOutSize);
^^ ^
Please recheck for pointer format vs. string argument mismatches.
--
Dmitry.
Chris Green [EMAIL PROTECTED] wrote:
I've been looking at this function, and I am starting to suspect we have the
wrong definition of CSIDL_FOLDER_MASK (currently 0x00ff). What I've been
seeing (eg. installing MS Office 97) seems to imply that only the lower 6
bits, rather than 8, are
[EMAIL PROTECTED] wrote:
Okay, I reported it, attached is an unexpurgated --debugmsg +edit trace
of me trying to open the lcc-win/lccpub/bin/wedit.hlp file from
ftp://ftp.mathematik.tu-darmstadt.de/pub/linux/bonnes/lcc-bin-alpha.tar.gz
with wine's builtin winhelp program.
Please let me know
Andreas Mohr [EMAIL PROTECTED] wrote:
this is a rewrite of OaBuildVersion().
Now we just return the highest version value possible (0x) and
have a config file option to tweak the version value to return if this
is causing problems.
Added docu for it, of course.
I suspect too much of
Ilya Konstantinov [EMAIL PROTECTED] wrote:
This patch adds a _NET_WM_NAME(UTF8_STRING) property to every window,
storing it's title in non-ambigous UTF8 encoding. This is a part of the
NET_WM standard. The UTF8 title feature is currently implemented only
by KWin (KDE's window manager), but
Hello all.
This patch fixes a couple of problems with keyboard group switching
reported in the news group:
1. Group switch had never worked before, if the keyboard has been
switched outside of Wine.
2. I was clearly stated that Group switch is active if event-state 0x2000,
not event-state
Nerijus Baliunas [EMAIL PROTECTED] wrote:
In my XF86Config-4 I have:
Option XkbLayout lt
Option XkbOptions grp:ctrl_shift_toggle - it means Ctrl+Shift switches layouts.
I switched layouts 2 times in notepad.
Without patch:
err:keyboard:X11DRV_ToUnicode Please report: no char for
Huw D M Davies [EMAIL PROTECTED] wrote:
Does this help?
Yes, it does. But application (a heavily modified MS glyph sample
from 1993) doesn't show anything. I could send you the source code
if you are interested to fix it.
--
Dmitry.
Patrik Stridvall [EMAIL PROTECTED] wrote:
Noticing that you (Dimitry) have send in a few patch
replacing Win16 calls by Win32 ones, I wish to
point out that winapi_check can detect illegal
calls from Win32 to Win16.
Just do
winapi_check --cross-call-win32-win16
Great! Why didn't you
Alexandre Julliard [EMAIL PROTECTED] wrote:
While the idea of the patch is correct, I think it would be much
better to fix the huge code duplication while everything is in the
same file. The 16-bit stuff should be implemented on top of the 32-bit
stuff, instead of duplicating most of it.
Marcus Meissner [EMAIL PROTECTED] wrote:
+ /* This might be a DOS device we do not handle yet ... */
+ FIXME((%) not detected as DOS device!\n,devname);
^^^
Seems a typo to me.
Francois Gouget [EMAIL PROTECTED] wrote:
* I scanned the source for TRACE/WARN/ERR/FIXME statements without a
terminating newline. There are few cases where this is justified because
of following DPRINTFs. But most of the time there should be a \n
otherwise the trace will not be flushed to
Marcus Meissner [EMAIL PROTECTED] wrote:
It works now much better, except it somehow cannot upload fonts(?) and
queries support for escapes 4568 and 4567 which are unknown to me.
PlatformSDK July 2000 defines
#define SPCLPASSTHROUGH2 4568 /* new escape for NT5 pscript driver */
Dan Engel [EMAIL PROTECTED] wrote:
Okay, here are the traces. Here
(ftp://sourceharvest.com/pub/wine_qb4.log.gz) is the QB4 trace. QB4
printing works.
The other (ftp://sourceharvest.com/pub/wine_qb5.log.gz) is the QB5 trace.
QB5 printing doesn't work.
Please try the attached patch.
Dan Engel [EMAIL PROTECTED] wrote:
Using --debugmsg warn+all,+relay,+text,+string I found that it's trying
to load wineps.drv.dll which translates into libwineps.drv.so. This
doesn't work, and it appears that the QB code is what's adding the .DRV to
the WINEPS print driver name.
I
Ulrich Weigand [EMAIL PROTECTED] wrote:
VirtualQuery in Win95, however, appears to completely ignore the
KERNEL32 list of views, but always calls the _PageQuery VMM service
and returns VMM's opinion on the status of the pages. This explains
why VirtualQuery shows the pages still present
I wtote:
Rein Klazes [EMAIL PROTECTED] wrote:
win95 on a vmware machine.
H:\test
hMapping = 0005
p = 826DB000
VirtualQuery(826DB000) ret=0x1c
BaseAddress = 826DB000
AllocationBase = 826DB000
AllocationProtect = 0x0001
RegionSize = 0x0400f000
State = 2000
"Rein Klazes" [EMAIL PROTECTED] wrote:
win95 on a vmware machine.
H:\test
hMapping = 0005
p = 826DB000
VirtualQuery(826DB000) ret=0x1c
BaseAddress = 826DB000
AllocationBase = 826DB000
AllocationProtect = 0x0001
RegionSize = 0x0400f000
State = 2000
Protect = 0001
Type =
"Rein Klazes" [EMAIL PROTECTED] wrote:
Exception occurs when pen-logpen.lopnWidth.x = 0 and dc-xformWorld2Vport.eM11 =
0.0
It's very strange. Attached patch helps to eliminate crash. But I don't understand
where the source of problem.
| 0x40897fde (X11DRV_PEN_SelectObject+0x8e
"Francois Gouget" [EMAIL PROTECTED] wrote:
I noticed that fs was replaced by tid in relay (and snoop co too
now). I propose a slightly different version based on the following
premises:
* when suspecting a threading problem it could be nice to tag each
trace with the id of the thread
"Ian Pilcher" [EMAIL PROTECTED] wrote:
Well, the only paper size missing is DMPAPER_11X17, presumable because
it isn't mentioned in Adobe's documentation.
For the bin types, if someone can tell me how to map the following PPD
file bin types, I'll do it:
Since we have a fairly limited set
"Ian Pilcher" [EMAIL PROTECTED] wrote:
Is it really appropriate to spit out a FIXME every time we encounter a
paper size or bin type that we don't recognize?
I would agree with you, if you have added all regular possible values listed
in wine/include/wingdi.h and only then replaced FIXME's by
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I think it would be better to keep the existing support for native
dlls, and simply fall back to loading the builtin library if
SearchPath fails.
Does the attached patch look as applicable?
module.c.diff
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I think it's reasonable to give the native dll priority when doing
LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the
dll binary file and we are much better off giving it the 'real' thing
in this case IMO.
Perhaps version.dll
[EMAIL PROTECTED] wrote:
I guess it doesn't look at all of it though. I will try later with
2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053,
so I guess 2.20.2054 is its minimum oleaut32.
Will you
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
I just don't like an idea to hunt down all that cases when some application will
want
that strange version numbers. Will 10.0 work for you?
Yes. I can't promise it will work for other apps, and maybe in time we
will have to go to "255.0" or something, but for
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
I guess it doesn't look at all of it though. I will try later with
2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053,
so I guess 2.20.2054 is its minimum oleaut32.
Will you
[EMAIL PROTECTED] wrote:
Strange, I tested my patch with About.exe and it worked for me.
From the trace you sent me directly my patch works just fine.
You could try replace version.rc by the following version resource, and
to see if it will help (even better try to use both and report
[EMAIL PROTECTED] wrote:
Nuts! Parse errors still, until I added
VS_VERSION_INFO VERSIONINFO
before it, then it compiles clean, but all values except Translation are
null. So I tried with this dlls/oleaut32/version.rc, and it works (if
you get this letter):
#define WINE_FILEVERSION
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
I guess it doesn't look at all of it though. I will try later with
2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053,
so I guess 2.20.2054 is its minimum oleaut32.
Will you
"gerard patel" [EMAIL PROTECTED] wrote:
Getting the common controls to the 4.72 version at least is the *whole*
purpose of the patch. There are applications testing the version number of the
common controls - tons of them : all the apps written with modern
Borland tools. Their behaviour
[EMAIL PROTECTED] wrote:
Now the question: How to load built-in dll without resolving its imports?
Where's the harm in resolving the imports of the builtin?
In this case, the app has already loaded and used oleaut32 before it
gets around to asking about its version.
If the dll already
"gerard patel" [EMAIL PROTECTED] wrote:
ChangeLog:
* dlls/comctl32/rsrc.rc
Add version info.
[...]
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
+
+1 VERSIONINFO
+FILEVERSION 4, 72, 0, 0
+PRODUCTVERSION 4, 72, 0, 0
+FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
+FILEOS
"Andreas Mohr" [EMAIL PROTECTED] wrote:
That hack cured the application, but Andreas
Well, that's not exactly true.
You did not do it "for edit control". You did it for *all* controls
in DIALOG_GetControl16() (at least in the patch you sent me).
That's why I objected. I just had to :)
"gerard patel" [EMAIL PROTECTED] wrote:
As it's rather unlikely anyone will craft 16 bits specific resources now, I have
mapped the 32 bits resource into 16 bit ones
I did not test if 16 bits printing still works, but the print dialog box displays
again
at least.
There is also a minor fix
"Ian Pilcher" [EMAIL PROTECTED] wrote:
+
+/*
+ * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to
+ * imagine why either of them would. And what is the calling function supposed
+ * to do about it anyway?
+ */
+
+#define REGCLOSEKEY(X) \
+{ \
+DWORD ret;
"Francois Gouget" [EMAIL PROTECTED] wrote:
rant
I checked the other cases and I have this question. Why does everyone
use 0 instead of '\0', 0 instead of FALSE, and '\0' instead of NULL? MS
even does the reverse and uses NULL in places where '\0' or 0 would have
been more appropriate. Man,
Gavriel State [EMAIL PROTECTED] wrote:
It's at http://opensource.corel.com
It hasn't been updated in quite a while, and the last import from
WineHQ was back in December '99, I believe. In addition to the
font/printing work, there may still be a few other outstanding fixes
that haven't made
Joao clemente [EMAIL PROTECTED] wrote:
...
: 2. There are two approaches in implementing support for DK:
: a. Do all the character composing in Wine itself, completely ignoring X.
You mean, having to write something like those tables that exist to handle
the keyboard?
Not at all. Those tables
Hello all.
Some time ago, when I was testing standard USER controls with the new unicode
stuff, I encountered the following problem not related to controls at all.
One of my test applications is Adobe PageMaker 6.5. It loads its plugins and
initializes menu with strings loaded from the plugin
"Joao clemente" [EMAIL PROTECTED] wrote:
I was thinking of changing the keybord settings in X11 so that I try to find
out something else about this matter...
Do you think it's worth triying? ( lame question : I do that in Xf86config
file, right?)
Btw... do you think I can read some
Ove Kaaven [EMAIL PROTECTED] wrote:
[skipped]
2. Accent characters in different code pages has different mappings to
unicode characters. Perhaps we just have to create internal table with
mapping [combining character in code page] - [combining character in unicode]?
Since the last deadkey
Ove Kaaven [EMAIL PROTECTED] wrote:
Sure, X11 should do it for us. Hints, please: what X11 dead-key stuff?
That's a good question. I don't really know, and don't have time to read
the Xlib manual right now (have to catch a flight in a few hours), but I
suspect it might have something to do
"Francois Gouget" [EMAIL PROTECTED] wrote:
Well, I'm not in France but I do sometimes use my qwerty keyboard in
'US-International' mode so that I can get some of these French
characters... via dead-keys. Of course it seems like half the Unix
applications don't support dead keys and the
Hello all.
While working on the problems with scrolling in the 16-bit notepad,
I tried to avoid loading file via File-Load-etc, but use command line
instead: wine -debugmsg +edit,+scroll notepad -- new.txt ~/notepad.log.
Unfortunately notepad seems to not correctly understand its command line
"gerard patel" [EMAIL PROTECTED] wrote:
Could you please add
if(!(es-style ES_MULTILINE)) return;
at the start of EDIT_UpdateScrollInfo and try that patch again?
Yes, it works with this change; this is not surprising, do you intend
this as a test or as a real fix ?
It was suggested
"gerard patel" [EMAIL PROTECTED] wrote:
While your patch makes the scrolling behaviour of the edit control better,
are you sure you could not get the same effect without this change ?
Yes, all works fine with this line in place. Alexandre, please ignore this
one-liner change for scroll.c. Or
"gerard patel" [EMAIL PROTECTED] wrote:
Wait, there is at least another problem with this patch.
It's about the access to the edit's parent control. Try this
with your patch : use any 32 bit program (I tested with
the Word 97 viewer, this happens also with Forte Free
Agent32) to open a
This patch works fine for me. Could you please test it too?
--- cvs/wine/controls/edit.cFri Jan 5 15:21:35 2001
+++ wine/controls/edit.cTue Jan 9 22:13:46 2001
@@ -1482,25 +1482,22 @@
}
if (!es-text) {
CHAR *textA = NULL;
- INT countA = 0;
+
"gerard patel" [EMAIL PROTECTED] wrote:
Do you have an application that doesn't work after the edit control rewrite?
Notepad 16 bits. The version I use for testing was coming with Wfw 3.11 I think.
I have searched a bit and the problem seems to be the buffer length.
The problem is that
"gerard patel" [EMAIL PROTECTED] wrote:
Please try this patch (I have no 16-bit notepad):
snip edit patch
I have tested it a bit, it seems to work fine as long as I edit text and
use disk access; I have tried clipboard (pasting text from the clipboard
into Notepad 16) and it was not
"gerard patel" [EMAIL PROTECTED] wrote:
Do you have an unicode version of listbox in the works ?
Yes, I'm working on it right now. After a general way of testing
I'll send it to wine-patches.
Since the combobox is unicode, cb_findtext* apis
seem to have problems; I think it should not
"gerard patel" [EMAIL PROTECTED] wrote:
[...]
- in X11DRV_IsClipboardFormatAvailable a call to
CLIPBOARD_IsPresent had disappeared; adding it again
get back the text exchange between Wine applications.
X11 clipboard driver should call only exported win32 functions IMO.
Driver doesn't need
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
GlobalAlloc/GlobalReAlloc: Make allocations with granularity 32
bytes.
Clear error on success in GlobalLock as Windows does.
What version does this? NT 4 definitely doesn't set last error on
success (and it doesn't seem to round up the
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I got this results running my test app that creates unicode and ansi edit
controls
and dumps their contents. Memory blocks are always 32-byte aligned.
Couldn't this be because the edit control does the rounding?
I made another test and it
Nerijus Baliunas [EMAIL PROTECTED] wrote:
Sorry, I didn't know that. I thought it is/was the same [EMAIL PROTECTED]
Updated patch:
[...]
-Patches should be submitted to "[EMAIL PROTECTED]". Please don't
+Patches should be submitted to "[EMAIL PROTECTED]". Please don't
Do you know that to post
Jon [EMAIL PROTECTED] wrote:
I'm having a problem implementing locale related functionality for crtdll.
Basically, I need to get an LCID from a locale string, rather than from a
locale id as used by the MAKELCID macro.
Which crtdll function does need this?
There doesn't appear to be a way to
windows: message.c winproc.c
Log message:
Dmitry Timoshkov [EMAIL PROTECTED]
Added mapping to/from unicode for WM_CHAR, WM_DEADCHAR, WM_SYSCHAR,
WM_SYSDEADCHAR messages.
Patch:
http://cvs.winehq.com/patch.py?root=/opt/cvs-commitlogs=/opt/cvs-commit/CVSROOT/winecommitlogid=97
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Thu, 16 Nov 2000, Dmitry Timoshkov wrote:
Hello.
Changelog:
Dmitry Timoshkov [EMAIL PROTECTED]
Always generate unicode CHAR messages.
Good day!
This broke my mail app. I have been running with it 'til now, so I
guess you could say
Ove Kaaven [EMAIL PROTECTED] wrote:
The first crash in civ2 that I didn't have a patch for goes like this:
First, it creates (hidden) windows and stuff, and
Call USER.100: DLGDIRLIST(0x01bc,0x07771dca "*.*",0x0064,0x,0x4000) ret=03e7:0ed8
ds=0777
... (DDL_DRIVES)
Ret USER.100:
Okay, things are simpler than they look.
Eyes are afraid - hands are doing (russian byword).
I have wrote a very simple sample that demonstrates bitmaps
in the menu (mono and 16 colors, you can add your own of course).
Selected color bitmaps are inverted in both win95 and win98,
but monochrome
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote:
ChangeLog:
dlls/comctl32/datetime.c
dlls/comctl32/header.c
dlls/comctl32/rebar.c
dlls/comctl32/status.c
dlls/comctl32/toolbar.c
dlls/comctl32/treeview.c
dlls/commdlg/filedlg.c
dlls/shell32/shlfolder.c
dlls/shlwapi/path.c:
fix for supporting
mark dufour [EMAIL PROTECTED] wrote:
Here's another implementation, for the PolyDraw function. Like AngleArc, this
is NT-only. I installed NT for the occasion and tried out all possible
situations I could think of. I also found a bug in my AngleArc
implementation, so I'm submitting that
Ove Kaaven [EMAIL PROTECTED] wrote:
Gerard is from France. French keyboards don't have a QWERTY layout, they
have AZERTY. I suspect Gerard just got the key reassigned to W...
Ah! It expalains all of it! I should notice it earlier by examining more
carefully the keyboard layouts (particularly
Ove Kaaven [EMAIL PROTECTED] wrote:
Some problems that I tried to solve:
1. I didn't find way to make to work XLookupString with setlocale(LC_CTYPE,"").
I don't know exactly how this works, but what is your locale settings? I
know that glibc and Xlib disagrees somewhat on the format of the
gerard patel [EMAIL PROTECTED] wrote:
[...]
I investigated further, without great success.
It's difficult to trace since the end of the trace disappear, I ended up adding
a sync() call at this point. What happens is that the main window (the one being
disabled) get an UnmapNotify event almost
James Hatheway [EMAIL PROTECTED] wrote:
I don't think your patch is causing these problems. I have these two same
Balsam for my soul...
problems in the app that I am debugging, without your patch applied.
(I get this problem with KDE 1.1.2) For me, when the app starts up
it has a normal
gerard patel [EMAIL PROTECTED] wrote:
[...]
If I test this patch with winedt (available from www.winedt.com), my
X-server crashes when I try to load the Options dialog box. Winedt is a
program written in Delphi I think; Borland has a very special system to
simulate modal dialog boxes; I see
gerard patel [EMAIL PROTECTED] wrote:
If I test this patch with winedt (available from www.winedt.com), my
X-server crashes when I try to load the Options dialog box. Winedt is a
program written in Delphi I think; Borland has a very special system to
simulate modal dialog boxes; I see the same
Hello all.
My app have a problem with repainting its menu in managed mode.
Funny, but it can be reproduced with old 16-bit clock.exe
from windows 3.1.
How to reproduce: Double clicking on the client area switches
clock modes: with menu (and caption) and without menu (and caption
in not managed
Hello all.
The question is short: is EnumResourceTypes supposed to work with
16-bit modules?
I ask because I don't know what to do: simply avoid crashing by
checking HIWORD(hModule), or implement a full working solution.
Dmitry.
Hello all.
Some traces +mdi and version of strlenW that prints result
before exit:
...
trace:mdi:MDI_UpdateFrameText AFTER lstrcpyW(lpBuffer): L"Adobe PageMaker 6.5"
trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5", L" - [")
strlenW(): 19 -- right
Ulrich Weigand [EMAIL PROTECTED] wrote:
I've now modified the CallTo16Register routines to save (some) register
values possibly modified by the called 16-bit routine back into the
CONTEXT86 structure. Saving *all* registers is difficult (or at least
would create more overhead), so I decided to
gerard patel [EMAIL PROTECTED] wrote:
[big snip]
If other had similar experiences, it would probably a good thing
to include in the how-to or faq that while Wine will work
correctly for most programs with glibc 2.0, it works best with
glibc 2.1 (apart from the infamous Redhat 2.1.3 problem, of
Hello all.
I'm still trying to solve problems with PageMaker and thunking...
Assuming, that problems arise with using QT_Thunk/SMapLS_IP_EBP_8/SUnMapLS_IP_EBP_8
functions (i.e. Win95 thunks), I guessed that -winver nt40 will solve at least some
part of the problem. But PM always used Win95
Alexandre Julliard [EMAIL PROTECTED] wrote:
"Dmitry Timoshkov" [EMAIL PROTECTED] writes:
Changelog:
Small correction for path stripping.
This breaks paths that contain both '/' and '\'. What are you trying
to fix?
Well, while I searched for a real culprit of crash with prin
Alexandre Julliard [EMAIL PROTECTED] wrote:
BUILTIN32_dlopen seems correct to me. Are you sure the problem wasn't
rather with BUILTIN32_LoadLibraryExA? We don't try to handle '/'
there, and maybe we should (but it has to be done the same way as in
BUILTIN32_dlopen, not the way you did it in
Alexandre Julliard [EMAIL PROTECTED] wrote:
I don't have any Russian fonts on my Windows machine to test this, but
if I select an OEM font TextOut definitely uses the OEM codepage, not
the CP_ACP one. So we cannot assume that all strings passed to TextOut
are in current ANSI codepage; we have to
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote:
I check original windows 98(Japanese edition; CP_ACP=cp932).
There are some system fonts that have codepage CP_ACP
(at least in my environments):
- System, FixedSys, Terminal
Probablly, these three 'reserved' fonts should be treated
as special font
Hello.
This patch broke correct displaying of cyrillic characters:
revision 1.28
date: 2000/08/20 20:08:35; author: julliard; state: Exp; lines: +20 -14
Hidenori Takeshima [EMAIL PROTECTED]
Handle the codepage of fonts if supported by the graphics driver.
because of:
1. My app loads
Francois Methot [EMAIL PROTECTED] wrote:
For the transparency issue, this patch implement a switch-case for the
bitcount (bit per pixel) of the animation files. With this switch different
line of code is executed for getting and setting the transparency color
whenever it's 2, 4, 8, 16, 24 or 32
Francois Methot [EMAIL PROTECTED] wrote:
This patch prevent a system menu from appearing on a docker by filtering the
Style and ExStyle of a window.
The system menu won't be displayed if a given window has the following
style:
WS_EX_TOOL_WINDOW
However to display it, it requires those:
Alexandre Julliard [EMAIL PROTECTED] wrote:
2. Then app displays the text using ExtTextOutA. Here the problems begin.
Now ExtTextOutA assumes, that ANSI code page and code page of currently
selected font is the same. It is wrong assumption. As it was many times
pointed out (at least by me).
301 - 400 of 437 matches
Mail list logo
