On Wed, 1 Sep 2004, Patrick Goupell wrote:
> The bug description mentions looking at the *.c and *.cpp source looking for
> main, WinMain and DllMain. Looking at the *.h source and looking for
> #pragma comment(lib, 'foo.lib').
>
> Is there anything else I should be looking for while I attempt t
Rein Klazes <[EMAIL PROTECTED]> writes:
> This has the effect that a program that like agent does this:
>
> case WM_PAINT:
> if( GetUpdateRect(hWnd, ...) {
> hdc = BeginPaint(hWnd,...);
>
> }
>
> causes a lot of:
>
> err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hw
Hi,
I am almost running an old DOS-based application using
wineconsole, but I am constantly being bombarded by
FIXME messages from the DOSVM's Int33 calls for "Show
mouse cursor" and "Hide mouse cursor".
I have tracked the relevant code down to
dlls/winedos/int33.c, but don't know how the DOSVM
d
Stefan Leichter <[EMAIL PROTECTED]> writes:
> +/***
> + * AtlUpdateRegistryFromResourceD [EMAIL PROTECTED] (.NET)
> + *
> + */
> +HRESULT WINAPI AtlUpdateRegistryFromResourceD(HINSTANCE hInst, LPCOLESTR lpszRes,
Rein Klazes wrote:
On Wed, 01 Sep 2004 10:02:43 -0700, you wrote:
Oops, not enough coffee yet this morning. Actually, the problem I was
having with Pegasus, that the patch attempts to fix, is with
minimization. That is, I minimize and then attempt to restore Pegasus,
and nothing shows up *excep
On Wed, 01 Sep 2004 10:02:43 -0700, you wrote:
>
> Oops, not enough coffee yet this morning. Actually, the problem I was
> having with Pegasus, that the patch attempts to fix, is with
> minimization. That is, I minimize and then attempt to restore Pegasus,
> and nothing shows up *except* the m
On Wed, 01 Sep 2004 09:52:40 -0700, you wrote:
> Rein Klazes <[EMAIL PROTECTED]> writes:
>
> > I was too early, another problem popped up caused by this patch.
> > Un-maximized MDI child windows don't paint their non client area anymore
> > (I tried two MDI applications, both had it).
>
> How ab
Rein Klazes wrote:
Hi Duane. Unfortunately your patch does not change anything (that is cvs
winpos.c + alexandre's patch + your patch).
Maybe I did not explain clearly enough: these windows show alright but
without painting the borders, caption, buttons etc. The defects also
show in applications wi
Rein Klazes <[EMAIL PROTECTED]> writes:
> I was too early, another problem popped up caused by this patch.
> Un-maximized MDI child windows don't paint their non client area anymore
> (I tried two MDI applications, both had it).
How about this one?
Index: dlls/x11drv/winpos.c
===
On Wed, 01 Sep 2004 09:06:27 -0700, you wrote:
> Rein Klazes wrote:
> >
> > I was too early, another problem popped up caused by this patch.
> > Un-maximized MDI child windows don't paint their non client area anymore
> > (I tried two MDI applications, both had it).
>
> I don't know why that onl
Mike (at yet another email address) wrote:
> Wines sockets support is good though, far better
> than its builtin DCOM. Based on what I know of the
> DCOM network protocol, I don't think we'd have any
> problems with it.
I can think of a couple, but they may be able to be
worked around:
- incoming
Of course, by the same reasoning, 95% of people are happy with the
way things work now, so why add complexity to make it relocatable?
And really, it's not that hard to do it right.
D'oh! Good point. OK, I'll see if I can knock something up.
Rein Klazes wrote:
I was too early, another problem popped up caused by this patch.
Un-maximized MDI child windows don't paint their non client area anymore
(I tried two MDI applications, both had it).
I don't know why that only showed up now, but I have a workaround that I
have been using for a l
Mike Hearn <[EMAIL PROTECTED]> writes:
> Still, I'm not sure why this has to be so generic. I think not people
> modify the standard install layout, and if they do, they probably
> don't care about binary relocatability. Why do we have to make the
> code so very complex to make it work for 100% of
The bug description mentions looking at the *.c and *.cpp source looking for
main, WinMain and DllMain. Looking at the *.h source and looking for
#pragma comment(lib, 'foo.lib').
Is there anything else I should be looking for while I attempt this?
>On Tuesday 31 August 2004 08:38 pm, you wrot
Mike, I was hesitating to give this answer. Typically OPC will be used
distributed, over an ethernet link. Did anyone test wine & native DCOM
in such a way? Can you actually communicate between an application
running under Wine with an application that runs under real Windows?
I'm not sure. I think
On Wed, 01 Sep 2004 11:09:37 +0100, you wrote:
> Rickard Svensson wrote:
> > My short question is:
> > Can I use Wine to make OPC communication work on a Linux system.
>
> Answer: almost certainly yes, with a catch:
>
> 1) Wines current builtin DCOM is not up to scratch for what you want,
> and
On Wed, 01 Sep 2004 12:45:16 +0200, you wrote:
> On Tue, 31 Aug 2004 18:10:22 -0700, you wrote:
>
> > Rein Klazes <[EMAIL PROTECTED]> writes:
> >
> > > Well, Pegasus Mail has the same problem with lists. And it is fatal: no
> > > mail in any mailbox is visible.
> > >
> > > The configuration dial
On Tue, 31 Aug 2004 18:10:22 -0700, you wrote:
> Rein Klazes <[EMAIL PROTECTED]> writes:
>
> > Well, Pegasus Mail has the same problem with lists. And it is fatal: no
> > mail in any mailbox is visible.
> >
> > The configuration dialog of Agent news reader has yet another problem,
> > disappearin
"Huw D M Davies" <[EMAIL PROTECTED]> wrote:
> Try setting lfWidth to 0, that should then scale the font
> isotropically - setting a non-zero lfWidth can result in different
> scaling factors in the x and y directions. So for example if you
> leave width set to the normal width and only multiply u
Rickard Svensson wrote:
My short question is:
Can I use Wine to make OPC communication work on a Linux system.
Answer: almost certainly yes, with a catch:
1) Wines current builtin DCOM is not up to scratch for what you want,
and it will take a long time to get there. Really, given how
unglamourou
On Wed, Sep 01, 2004 at 06:49:14PM +0900, Dmitry Timoshkov wrote:
> "Huw D M Davies" <[EMAIL PROTECTED]> wrote:
>
> > > I had a wild guess whether GDI actually scales or not metrics for
> > > a bitmap font if a requested font size is not available and wrote
> > > a test case for it. No, GDI *does
"Huw D M Davies" <[EMAIL PROTECTED]> wrote:
> > I had a wild guess whether GDI actually scales or not metrics for
> > a bitmap font if a requested font size is not available and wrote
> > a test case for it. No, GDI *does not* scale bitmap font metrics.
>
> Well it does do integer scaling. So if
Hello!
I have some questions about Wine and how/if it can be used with industrial
communication like OPC (MicroSoft Com/DCom objects, DDE and more)
My short question is:
Can I use Wine to make OPC communication work on a Linux system.
OPC "OLE for Process Control"
A "general" standard for comm
On Wed, Sep 01, 2004 at 05:44:19PM +0900, Dmitry Timoshkov wrote:
> Hello,
>
> I had a wild guess whether GDI actually scales or not metrics for
> a bitmap font if a requested font size is not available and wrote
> a test case for it. No, GDI *does not* scale bitmap font metrics.
Well it does do
This is still making assumptions about the contents of bindir and
libdir. What you need is a generic way to find a relative path from
any directory to any other. Also this needs to be done at make time,
not in configure.
I realised last night the patch I sent in was incomplete anyway, I
missed the
On Tue, 31 Aug 2004, Alexandre Julliard wrote:
> Does this help?
>
> Index: dlls/x11drv/winpos.c
Yes, the patch helps in my case. Thanks.
27 matches
Mail list logo
