( I have posted a similiar question in wine-users,
don't flame me for doing so, just thinking about this
some more, perhaps it may be more a developer question
)
Ok, I have a windows app, that runs under wine fine -
not quite. This app has a form, with many text field
edit boxes on. Quite often these edit boxes already
have text values, ie. they are not empty - there is a
database behind the form.
Anyway, the form shows on the screen, but the text
within the edit fields is invisible, until you
activate each edit box component. When you leave one
edit box to the next, the text remains visible.
It seems like the repainting is not working, on
initial startup of the form.
As a way to debug this database app ( I don't have the
source code for it ) I wrote a real basic form app in
Visual Studio, with two edit boxes, with data in each.
Now this basic app shows the text values immediately
on startup. So there must be something different that
the database app is not doing.
I then ran wine using 'wine --debugmsg +edit
programname' for both app's.
I see both logging 'Creating ANSI edit control, style
= xxxxx'
but the style reference is different between apps - I
am not sure if this the cause or not.
The problem app reports style = 54011104 and the basic
app shows style = 50010080.
Can somebody explain what this style reference means
and how do I force an app to use a certain style of
edit box ?
What other wine class debugmsg types should I use to
narrow down the source of this problem ?
Is there anyway I can check to see how the database
app is repainting text within the text edit components
?
Regards
Doug Herbert.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
I put together the following:
http://users.theshell.com/~vinn/wine-history.html
There's two major additions I'd like to see and I
don't think I'm capable of doing them:
1) Wine history from 1994 - 1999 with a specific
emphasis on changes to the architecture, design
decisions that got discarded, developers who've
come and gone.
2) Specific quotes from over the years. I sort of
put some examples of that in the document above.
Humorous quotes would be especially nice. If no
one has any suggestions then I'll likely just remove
the existing ones and add the information to the
relevant paragraphs.
I'm also thinking of adding a paragraph on the tools
and programs developed for Wine.
Comments / suggestions / criticisms?
---------------
Brian Vincent
Copper Mountain Telecom
vincentb(a)coppercolorado.com
Hi folks,
I've finally managed to do the table I've promised for so long.
My appologies for the delay.
This has been mind numbing work, and as such I haven't payed
that much attention to the values I've filled in those columns.
Please send me your comments so I can post a final version
of this to the WineHQ site soon.
Note: best viewed in a web browser, but an editor that can
display about 150 columns would do just fine as well.
--
Dimi.
Hi Jon,
Can you please explain why VARIANT_ValidateType rejects for instance VT_SAFEARRAY
variants (and more) with DISP_E_BADVARTYPE?
Why does it handle the whole range VT_HRESULT - VT_CF as invalid (except VT_RECORD) ?
We got one InstallShield regression from this patch (where it wants to clear
a VT_SAFEARRAY I think).
Ciao, Marcus
Hi,
The conformance tests fail for the 20031016 build on my system with the following error message:
../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so msg.c && touch msg.ok
msg.c:333: Test failed: ShowWindow:overlapped: in msg 0x0047 expecting wParam 0x47 got 0x0
I haven't gotten this error until recently. My system is fairly ancient, it's a debian woody installation
with the latest version of KDE.
A new tarball of valgrind modified to work with WINE is available from the
valgrind home page:
http://developer.kde.org/~sewardj/http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
use a current CVS or the latest snapshot of WINE.
Seeya,
Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.
Hi,
I am currently trying to move my application porting environment from
Debian unstable to Red Hat 9. I thought this would not be a problem, but
I get unexpected linking errors (see below).
I copied the sources (that compile and link fine on the Debian system)
to the RedHat 9 environment, which provides gcc 3.2.2 and libc-2.3.2.
Furthermore, I installed the latest rpms of 20031016 that are hosted on
the sourceforge.net site.
Compiling the sources still works, but linking fails. Here's my example
for finally linking all object files together:
gcc -shared -Wl,-Bsymbolic,z,defs -L/usr/lib -L/usr/lib/wine/wine -lm
-lc -lwine -lstdc++ -lgcc_s <all object files> -o lib<mydll>.dll.so
On RedHat, however, this fails with the following linker error:
/usr/bin/ld: lib<mydll>.dll.so: undefined versioned symbol name
fprintf@@GLIBC_2.0
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
What I found googling through the net is that these conflicts may be
caused due to other libraries that may have been linked with earlier
versions (like in this case the striking GLIBC_2.0, which I cannot make
any sense of). However, since I only link with Winelib libraries of the
latest release, this does not make too much sense to me. Furthermore, I
found the advice to interchange the include-sequence of the libraries,
but this does not change anything. Furthermore I made sure that I do not
carry any old object files with me from previous builds, although I
never build against any GLIBC2.0 libaries...
Any help would be appreciated, thanks very much!
Cheers,
Martin
--
Hi all,
I have placed on my site the slides for a presentation I gave at a local
LUG about Wine. The slides are in English, in PDF format. You can get
them at http://shemesh.biz/lectures.html
The lecture was given several months ago, but I'm going to repeat it in
about a month. If you have any comments, please send them over for
inclusion for next time.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Hi,
On Sat, Oct 25, 2003 at 02:23:17PM +0200, Marcus Meissner wrote:
> Hi,
>
> Make Winword 2000 work again.
>
> I do not know, why it does outb $al,0x70, inb 0x71, $al ...
>
> And I am _afraid_ to ask.
Why, that's perfectly ok... Just imagine your feeling if it also did:
outb $al,0x70, outb al, 0x71
;-))
That only goes to show what a crappy piece of !@#$@$% Winword 2000 is...
> + if (INSTR_EmulateInstruction( epointers->ExceptionRecord, epointers->ContextRecord) == ExceptionContinueExecution)
> + return EXCEPTION_CONTINUE_EXECUTION;
BTW: Thanks!! This will most certainly fix my JTAG parallel port
flashing tool (I already reported it, but nobody fixed it,
and the result of "time * need" was too low...).
--
Wir kommen alle als Original zur Welt, aber die meisten von uns
sterben als Kopien (Autor unbekannt)
Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> Add proper casts to avoid signed vs. unsigned mismatches in strmake().
> - if (n > -1 && n < size) return p;
> - size = min( size*2, n+1 );
> + if (n > -1 && (size_t)n < size) return p;
> + size = min( size*2, (size_t)n+1 );
Once at it, could you please explain to me what the hell is
going on here (min)? I came across this function recently,
and do not agree with its logic. I would write it like
char *strmake(const char *fmt, ...)
{
int n;
size_t size = 100;
char *p = xmalloc (size+1);
va_list ap;
va_start (ap, fmt);
n = vsnprintf (p, size, fmt, ap);
while (n < 0) {
size *= 2;
p = xrealloc (p, size+1);
n = vsnprintf (p, size, fmt, ap);
}
if ((size_t)n == size) p[size]=0;
va_end (ap);
return p;
}
By the way, either Wine's snprintf implementation is wrong
or I do not know how to use it correctly. I am submitting a
conformance test...
--
Feri.
