Hi there,
this is my first wine patch.
it allows the coder to get the X11 Window Id
of a HWND.
People ask me why this belongs into x11drv
and why i need it.
ActiveX support for Konqueror, Malte Starostik
(who will post some oleaut and urlmon patches soon)
and me are working on this.
I need to embed the created window, therefore
i need this window id.
Thank you in advance
Bye
Bye
Niko
--
Nikolas Zimmermann
wildfox(a)kde.org
At 10:46 PM 25/05/2001 +0200, you wrote:
>I downloaded ftp://ftp.supermemo.com/ftp/sm8zip.exe and managed to
>reproduce the bug. (WINE version 20010510)
>The way:
>1) Using mouse chose File>SuperMemo
>2) When app changes its mode click at capition of window
>"Contents: E:\SM8\SYSTEMS\SUPERMEMO"
>And now main menu is inaccesible (using mouse)
>When you force wine to repaint all windows (eg. switch to linux console
>and back to X-Window ) you can see menu is drawn up 10-20 pixels than
>it should.
All right, I still can't see this bad redrawing , but I can see the menu not
accessible behaviour now.
I'll try to understand something in this problem this week.
Btw, this app does not work at all for me in managed mode, it hangs after
displaying the splash screen. (but sm7.exe - version 7.5 and sm99.exe - version 9
both load). I think it's an unrelated problem though since it happens with my
oldest wine version (20000801) and it's not fixed by your patch.
Gerard
This program may help creating ICOM_ macro.
(but this code doesn't have portability,
so some modification may be required.)
for example, if give the following codes to stdin,
we gets ICOM_ macros for IPersist.
class IUnknown
{
public:
HRESULT QueryInterface( REFIID riid, LPVOID *ppvObj) ;
ULONG AddRef() ;
ULONG Release() ;
};
export interface IPersist : public IUnknown
{
virtual HRESULT STDMETHODCALLTYPE GetClassID( CLSID *pClassID );
};
Hi,
This patch is an answer for "Call for volunteers".
I hope it fixes : "wrc fails on preprocessed files"
#115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115
Maciek
Changelog
* tools/wrc/ppy.y
Maciek Kaliszewski <kenon(a)go2.pl>
Added better GCC-style #line directive handling.
--
Has any thought been given to enabling backing store on Wine's windows?
As it stands now, when you obscure a Wine window, it forces the Windows
app to redraw the screen. Many times this is not needed. Perhaps a
configuration option to allow certain apps to have backing store on
would be useful.
I know that up until a few months ago, it was possible to go into wnd.c
and change the default from NotUseful to WhenMapped and things seemed to
work well. However, the structure of the X driver has changed, and a
simple patch is no longer possible.
David.Goodenough(a)dga.co.uk wrote:
>
> I have noticed that with the latest Wine (May drop) I have started to get X
> Errors. This typically happens as a dialog is being dismissed.
>
> The latest of these errors read:--
>
> X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 12 (X_ConfigureWindow)
> Resource if in failed request: 0x1c24350
> Serial number of failed request: 9920
> Current serial number in output stream: 9922
>
> I get the feeling, although I can not prove it, that this may be timing
> related, as it tends to happen when I am a bit quick completing the dialog.
> The other odd thing that happens when this occurs is that a second copy of
> the window, not the detail face of the window, just the window and its
> frame controls, is drawn slightly down and right of the original window,
> then it blows and Notes hangs.
>
> I had not noticed this behaviour before switching to the May drop. There
> are no other console messages that are out of the ordinary set that I have
> been reporting for a while.
>
> Is this a known problem?
David -
I have also seen this problem, but I have no idea what causes it.
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is there anybody out there who uses Exceed on NT4 as the X server to display
wine applications (like winemine from examples) which have been started on
Linux?
If yes are did you try 20010510 snapshot (or CVS) to run your applications?
If yes could you provide me with your configuration files? I am still not
able to start winemine since snapshot 20010418 (20010326 works fine).
- --
Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax : +49 271 48950-50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7DgpMpm53PRScYygRAn6cAKDaQl3Tm4l/sIe9cQoRbdwo7vf7bwCg8gm5
38OwXBWHUxJVc1ZV91iywRY=
=CjPM
-----END PGP SIGNATURE-----
Ian Pilcher <ian.pilcher(a)home.com> writes:
> Here's a thought. How about creating a data subdirectory for the Post-
> Script driver (i.e. dlls/wineps/data). The data could then be put in
> separate files in that directory without confusing things. (The data
> isn't interdependent from a build point of view, just from a main-
> tenance point of view.)
>
> I don't know the Makefile magic necessary to do this, but if someone
> could step forward with that piece, I suspect it would address both of
> our concerns.
>
> What do you think?
That's certainly a viable solution yes. If you send me a patch
implementing the separate files I'll do the Makefile magic.
--
Alexandre Julliard
julliard(a)winehq.com
Ian Pilcher <ian.pilcher(a)home.com> writes:
> I actually gave quite a bit of thought to the large file issue before
> submitting it, and I would agree with you if there were any functional
> code in the file. Because it's entirely data, and it's heavily
> interdependent, I really think that one file is better.
I disagree. If the data is so interdependent that you cannot split the
file, you are doing something wrong IMO. And in fact splitting it will
help enforce a clean data structure, which is a major advantage.
> From a build point of view, gcc has no problem at all with the file. In
> fact it compiles much faster than many of Wine's functional files.
I know some older versions of gcc had problems with large data
structures, using exponential memory to compile them or something like
that.
> If a
> target compiler (does Wine build with anything other than gcc?) does have
> a problem with it, I will yield to necessity. Until that happens, how-
> ever, I believe that the practical benefit of maintainability outweighs
> stylistic concerns. (After all, it's not like anyone will ever need to
> read all the way through the file to understand it, as is the case with
> functional code.)
You may not need to read every single line, but you still need to go
through it if you want to understand the structure (this is how I
noticed it was too large...). So please consider splitting it.
--
Alexandre Julliard
julliard(a)winehq.com
Forgot to cc wine-devel.
Alexandre Julliard wrote:
>
> You should really split it into separate files, a 40,000 lines file is
> a bit too much. Also all this data must be constant and in a read-only
> section, it's eating 400k of data space right now.
I actually gave quite a bit of thought to the large file issue before
submitting it, and I would agree with you if there were any functional
code in the file. Because it's entirely data, and it's heavily
interdependent, I really think that one file is better. (As the person
most likely be tweaking the data in the near future, I can tell you that
having a single file to edit, albeit a long one, will be heck of a lot
easier than having 39 separate files, and isn't that really the point?)
>From a build point of view, gcc has no problem at all with the file. In
fact it compiles much faster than many of Wine's functional files. If a
target compiler (does Wine build with anything other than gcc?) does
have
a problem with it, I will yield to necessity. Until that happens, how-
ever, I believe that the practical benefit of maintainability outweighs
stylistic concerns. (After all, it's not like anyone will ever need to
read all the way through the file to understand it, as is the case with
functional code.)
I would like to make the data constant, but that would require major
surgery to afm.c, which is more than I can take on at this point. Keep
in mind that the same amount of memory is being used currently; it's
just
dynamically allocated as the AFM files are read in.
>
> I'm guessing that you have a script to generate all this; could you
> please consider submitting it? This way other people can make changes
> too.
>
I have attached the two programs I use to generate agl.c. I have always
intended to submit them, but didn't know where in the source tree to put
them.
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================