Hi
I get this warning when I try to start a basic program. This comes from the
function VARIANT_GetLocalisedNumberChars. I added some printfs and
found that my currency is apparently "SFr.", so 4 chars plus zero which
is too much for the 4 char buffer. Strange though that on the command line
it looks differently:
locale -k LC_MONETARY
int_curr_symbol="CHF "
currency_symbol="Fr."
mon_decimal_point="."
mon_thousands_sep=" "
mon_grouping=3;3
...
Anyway, I thought I increase this buffer. But then the string gets stored
in two separate variables (each one char) in the VARIANT_NUMBER_CHARS
struct. Is there a reason that this is not a string? Why only two chars?
Thanks
bye Fabi
Hi Boaz,
I've looked at the potato-factory, and to be honest I don't
like the interface. The very fact that I have to logon before
I can see anything makes it fairly useless for me.
Now, before and put in too much infrastructure, I think we
can start small as follows:
-- have people submit material to wine-devel
-- various folks (volunteers needed) will collect them
and post them in a nice, orderly manner to a special
area (TBD) on WineHQ
This has the advantage of being a lot more controlled, and
I'm sure the editorial review will pay off. If the volume
becomes too big, we can consider in the future to automate
the process. But until then, I think the manual approach is
better.
--
Dimi.
Hallo,
I am trying to debug a problem with builtin MSVCRT. Is there any easy way to
deviate calls from builtin msvcrt to native msvcrt.
At present I have renamed native msvcrt in the wine system directory.
Then in the builtin msvcrt I call a function and for that function I do a
LoadLibrary(<renamed native msvcrt>) and a
GetProcAddress(hinstofrenamendmsvcrt,<original function) to finally call
that procedure.
I experimented with the forwards in the spec file, but didn't succeed.
Is there any easier way?
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Hi,
Winedbg catches the exception raised and handled in a
__TRY/__EXCEPT/__ENTRY statement in the IsBadReadPtr function.
Is it a normal behaviour? And if yes how can I disable it?
Without Winedbg everything is fine.
Thanks in advance,
Bye,
Christian
Hi,
I'm having some rebar issues with a particular application (Canon
File Viewer Utility).
The rebar is meant to look something like:
|0--------------- |1------|2---|
|3------|4------|5------|6------ |
(and there are some extra hidden bands)
Instead in wine the result is:
|0--------------- |||
|3------ ||||
with the remaining bands having 0-size child windows (and there's
important functionality in those bands). The minimum sizes
provided by the application seem to be right. The application then
requests maximisation of 0,3,4,5,6 in that order, which isn't
implemented in WINE so that should not do anything, but I'd still
expect the minimum sizes to be honoured.
The output of wine --debugmsg +rebar is at:
http://www.cse.unsw.edu.au/~matthewc/rebar.gz (62K)
I'm currently trying to understand the source, but if anyone is
familiar with the rebar and has any suggestions that would be
much appreciated.
Thanks,
Matt
Yorick Hardy a écrit :
> Changelog: Use SHN_UNDEF instead of STN_UNDEF when it is defined
> and STN_UNDEF is not. Fixes compiling on NetBSD 1.6.
>
>
> Kind regards,
>
both STN_UNDEF and SHN_UNDEF exist in ELF definition and are meant to be
used in different cases, which your patch mixes. Hence the fix is wrong
(even if by change STN_UNDEF and SHN_UNDEF both are defined as 0)
So, I'd rather suggest something (at the top of the file) as
#ifndef STN_UNDEF
# define STN_UNDEF 0
#endif
A+
Hi
While testing more variant functions I tried this on Windows:
double dVal;
OLECHAR test1[]={'&', 'H', '8', '0', '0', '0', '0', '0', '0', '0', '\0'};
ok=VarR8FromStr(test1, LANG_NEUTRAL, NUMPRS_STD, &dVal);
The result for dVal was -2147483648. But as a real value it shouldn't
have any problems holding the "real" value 2147483648. So why has
it become negative? Is it because the source form was a hex number?
Are all hex numbers automatically signed if converted to int/real? Or
just because of the 32nd bit? The documentation wasn't that informative.
(The funny thing though was this remark in my VC6 help, it's not
in the online version of MSDN anymore:
Passing into this function any invalid and, under some circumstances, NULL pointers will result in unexpected termination of the application. For more information about handling exceptions, see Programming Considerations.
...now I understand many things :)
Thanks
bye Fabi
Hi (I'm new in that group and don't know much about
wine, so I'm sorry in advance if my question is
in-proper)
Here is my problem:
I wrote in windows com object, and registered it in
wine using regsv32 utility. I also wrote a com client
application.
When I executed the client code using Wine, all was
just OK, and the client successfully make a reference
to the server and activated It. :-)
my question is there any way to write a client on the
native (Linux) using g++ and activation the com
object?
does it make a difference if the com object id a dll,
exe, or ocx ?
10x Yonatan
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
> Yep, should have the first version of this service this week sometime.
>
> Thanks,
> Chris
>
>
>> Amen. Not everyone need to "make crosstest". We would come a long way
>> if testers instead could install the Windows service (not yet written)
>> that downloads
>> the latest crosstest EXE from winehq and runs it.
Speaking of which, SourceForge seems like the ideal way to build
nightly Winetests by using their compile farm. I've been trying
to get access to it for a few days in order to figure that out.
All of the pieces seem to fit together and the only unknown is
whether or not they have mingw on their servers. Does anyone
else have any suggestions how we could create nightly builds?
-brian
Hi Marcus
Do you need a little(est) test with full source code that hosts an OCX
(The OCX is IE but I can change it if you need). It is written with
ATL/WTL. It will work fine with: "oleaut32"="native" but will crash with
"oleaut32"="builtin". I also have a winelib that crashes the same (same
code), but contact me personally if you need the source for that. (I
could post the .exe.so with full debug info)
I would give it a shut, but it will only be months from now. It didn't
look very simple, but maybe I am wrong about that.
Free Life
Boaz
