Well, if you really need a setup program, we can always write a
programs/winesetup program. So there is no need for a -init switch. Just run
winesetup -- it will have access to all Windows API. But for this particular
function GetComputerName, we can always code it like this:
val = get val from
Why don't we simply use gcc preprocessor?
Because not everybody uses/has gcc to compile wine...
This is certainly NOT a reason:
(1) who is compiling Wine with anything else? Can it be done?
(2) they may not have a Unix OS to run it for. This does not mean that we
include a Unix like OS
Along with transition to internal unicode implementation, I think
it should be possible to separate 16-bit parts from 32-bit ones.
I would also love for this to happen because, IMO, it clutters the code. But
my opinion is biased, since I don't care much about the 16bit part -- I
would like to
From: "Patrik Stridvall" [EMAIL PROTECTED]
Please note that there are some cases in which the encoding is
determined by the user specified OS version.
Yeah, these are trivial to deal with, once we can mark the encoding.
Now, we can do two things:
1. [eager] conver at the entry point
Now, I initially started this thread by saying that I was
trying to _eliminate_ our internal API as much as possible,
and simply use the std. Windows API. My motivation is twofold:
1. The Win API is huge enough as it is, it is no point in inventing
functions with new semantics for no good
From: "Patrik Stridvall" [EMAIL PROTECTED]
Yes, we need to fix them that is not a big deal.
Perhaps we can autogenerate them somehow.
The spec files know or can be told what is
strings or what is not.
Auto-generation will make me happy, because I think it is the only way
to (1) remove
On Sat, 29 Apr 2000, David Elliott wrote:
Which would be generated from a function like:
/* START ATOW */
DWORD BarW( LPSTR lpString1, DWORD cbString1 )
/* END ATOW */
{
/* DO STUFF */
return 0;
}
I don't really see a need for this kind of ugliness. We know that a xxxW
On Sat, 29 Apr 2000, Alexandre Julliard wrote:
I don't think there is enough regularity in the Windows API to make
this glue worthwhile. If you really want to cover more than a small
minority of cases you'll need to invent a glue syntax that will be at
least as complex as the generated
I change subjects a little to address another issue that has bugged me for
a considerable amount of time.
As we go forward and switch our base implementation to be 32W, the
16 32A subsystems become devoid of semantics. They simply contain code
that does:
16 - 32A
32A - 32W
Now, all this
Every time I do a cvs update -A I get the following:
cvs update: move away documentation/samples/system.ini; it is in the way
C documentation/samples/system.ini
It started a few weeks ago, don't know why. I usually do:
rm documentation/samples/system.ini
cvs update
Sorry, I forgot to mention that there is one more peculiar thing when I
try to correct the problem:
[dimi@decebal wine]$ rm documentation/samples/system.ini
[dimi@decebal wine]$ cvs update documentation/samples/system.ini
cvs [server aborted]: no such directory `documentation/samples'
U
From: "Marcus Meissner" [EMAIL PROTECTED]
Log message:
Gerald Pfeifer [EMAIL PROTECTED]
Use stdlib.h instead of the deprecated and non-portable malloc.h.
We should not use malloc at all. We should use HeapAlloc there...
True, but we do need malloc in x11drv.
--
Dimi.
From: "michael cardenas"
Here they are again...
Aren't some of these patches reversed?
--
Dimi.
On Sun, 21 May 2000, gerard patel wrote:
* documentation/bugreports
Regression testing using Cvs
A quick question:
-- why do we need a local CVS repository? Why can't we use the WineHQ
one?
(Sorry for asking without trying first, I feel rather leazy now... :) )
--
Dimi.
On Sun, 21 May 2000, Andreas Mohr wrote:
instead of doing
FIXME( "FATAL: Need to relocate %s, but no relocation records present
(%s). Try to run that file directly !\n",
filename,
(nt-FileHeader.CharacteristicsIMAGE_FILE_RELOCS_STRIPPED)?
On Sun, 21 May 2000, Andreas Mohr wrote:
I know that this approach isn't optimal. But can that be improved somehow ?
By using such a file we could add localized error messages easily, too.
Just use the format string as the key. Why introduce a number that must be
maintained by hand?
--
Dimi.
On Sun, 21 May 2000, James Sutherland wrote:
On Sun, 21 May 2000, Dimitrie O. Paun wrote:
On Sun, 21 May 2000, Andreas Mohr wrote:
I know that this approach isn't optimal. But can that be improved somehow ?
By using such a file we could add localized error messages easily, too
On Sun, 21 May 2000, gerard patel wrote:
At 02:53 PM 5/21/00 -0400, you wrote:
What do you mean. Right now you get both the filename and line
number. Isn't that enough?
I was believing the subject was trace ? Here is what was in Andi's first post:
FIXME( "FATAL: Need to
On Thu, 25 May 2000, Huw D M Davies wrote:
On Thu, May 25, 2000 at 01:06:51AM -0400, Dimitrie O. Paun wrote:
a. I did not know what to do with the DRIVER_RegisterDriver call; I just
took it out (as there is no longer such a call in x11drv). This is our
internal API so it has to go
It is down again (since yesterday).
This is becoming a big problem. I manage to squeeze a few minute weekly to
work on Wine, and most of the time the CVS server is down -- it kills the
little time I have between 1 other things I must do. I am sure I am not
the only one in this situation.
On Sat, 27 May 2000, Ian Schmidt wrote:
There are 3 CVS mirrors for Wine:
:pserver:[EMAIL PROTECTED]:/home/wine
:pserver:[EMAIL PROTECTED]:/home/wine
These two are down.
:pserver:[EMAIL PROTECTED]:/home/wine
I've never yet seen all 3 down at once :-)
Even so, it is (at the very least)
On Sun, 28 May 2000, Andreas Mohr wrote:
What's much more important is the WineHQ homepage.
And this is where lack of accessibility is a problem.
But SourceForge allows one to have their own homepage. No problem -- we
don't lose any control there. Did you check out SourceForge, btw?
--
Dimi.
On Sun, 28 May 2000, gerard patel wrote:
Hmm, the syntax of my command line is now obsolete :-); in fact it was :
wine "c:\winnt\winhlp32.exe d:\borland\Borland Shared\MSHelp\win32.hlp"
I had to change it to
wine c:\\winnt\\winhlp32.exe d:\\borland\\Borland\ Shared\\MSHelp\\win32.hlp
Hello everybody,
I am glad to see that Corel will host winehq from now on.
Not knowing this, and wanting to secure the
project name of SourceForge, I registered wine on SF:
http://sourceforge.net/project/?group_id=6241
Anyway, I don't know what we can do with it, but keep it in mind.
(the
From: "Douglas Ridgway" [EMAIL PROTECTED]
It's not a bad idea to develop a relationship with them. For example,
they've got a giant compile farm which might come in handy for regression
testing someday.
True. Moreover, I am pleasantly impressed with their stuff in general, so it
can be only
I find it slower.
Moreover, I can't seem to be able to create diffs:
[dimi@decebal wine]$ cvs -q diff ../wine-user-1.diff
cvs server: failed to create lock directory in repository
`/home/wine/wine/dlls/kernel': No such file or directory
cvs server: failed to obtain dir lock in repository
1. The cvsweb runs on an old copy of the tree. This is most likely the
result of the fact that the tree is not updated properly
2. If you try to get a specific version of a file, you get:
Error
Error: Unexpected output from cvs co: cvs checkout: Sorry, you don't have
read/write access to the
From: "Sam Dennis" [EMAIL PROTECTED]
When did InstallShield start working? Was I asleep at the time?
The wonders of separate address spaces... :)
--
Dimi.
From: "Jeff Tranter" [EMAIL PROTECTED]
- all APS specific code is conditionally compiled
I find the use of #ifdefs really ugly -- it makes
life so much harder later on. A lot of the #ifdefs
that you are using are not actually necessary. For
example:
+#ifdef HAVE_SYSAPS
+#include
From: "Alexandre Julliard" [EMAIL PROTECTED]
"Dimitrie O. Paun" [EMAIL PROTECTED] writes:
Here, do the same trick in the Makefile that we do for the X11 (and
OpenGL)
stuff -- simply do not try to compile the file if !HAVE_SYSAPS.
I agree with your other objections, b
From: "Alexandre Julliard" [EMAIL PROTECTED]
Yes, if you only consider systems using a recent glibc and a
thread-safe Xlib.
True. But, I guess, we can assume that for Linux-based system,
right?
I doubt you will have much success with a proposal
that we should stop supporting all other
From: "Alexandre Julliard" [EMAIL PROTECTED]
Sure. I am not proposing to drop other systems, but just for my
information, the other systems are AFAIK, FreeBSD and Solaris.
Are you referring to these systems? In any case, for platforms
were we can not do that trick, we are not 100%
Note that the X11DRV_CritSection is sometimes implicitly relied
upon to protect things other than the X11 libraries. For example
the use of the large stack is protected only by this critical
section ...
That's exactly what I was afraid of. Now, there are (mainly) two
places where we have
Hi people,
For the longest time I wanted to be able to look at
some of the changes that make it into the repository.
It is a great way to review code, follow the latest
changes, and understand/learn new code areas.
For the time being, one can (partially) do that by
reading the diffs sent out by
On Wed, 30 Aug 2000, Marcus Meissner wrote:
It would be better and nicer if the wine-cvs log_accum script could
generate mails that include the revisions of the affected files (could even
send to another mailinglist wine-cvs-verbose or similar).
This is exactly what I did. Is my proposed
On Fri, 15 Sep 2000, David Howells wrote:
Would it be possible for me to store a copy of my kernel module code on
winehq? Or should I find somewhere else (eg: sourceforge)?
There is a wine project on sourceforge...
--
Dimi.
From: "Stephane Lussier" [EMAIL PROTECTED]
Here's a patch trying to implement the TOPMOST feature of Windows. As some
of you probably know, there's no way to set a window as topmost in X.
Well, this is something that probably the WMs can handle -- maybe we should
suggest that they add some
On Sat, 16 Sep 2000, Ove Kaaven wrote:
Oh no, the most obnoxious mailing list manager in history, and now WE too,
the glorious WineHQ, will fall victim to its evil ways? There's nothing
that annoys me more about subscribing to a list than seeing that the
subscription address isn't
From: "Peter Hunnisett" [EMAIL PROTECTED]
just noticed that there's a, what I would consider, oversight for the
generated listing that's sent out; it doesn't provide a diff of new files.
No oversight, it was by design -- I can be persuaded either way. What about
deleted files?
--
Dimi.
From: "David Elliott" [EMAIL PROTECTED]
wine-doc: All kinds of wine documentation. Don't forget to use the
appropriate macro for the docdir as some RPM systems use /usr/doc while the
newest redhat has gone to /usr/share/doc to be more inline with the new
filesystem standard. However, it
Well, it looks like it's time for discussions about the future of Wine.
So, here is something that has been on my mind for quite a while now: the
build system.
In a nutshell, we should have a build system that allows building Wine in
a variety of ways: different compilers, output formats, etc.
We use:
#include some-libc-hdr.h
but we do:
#include "our-wine-hdr.h"
why? Shouldn't these be (in 90% of the cases):
#include our-wine-hdr.h
No?
--
Dimi.
On Thu, 2 Nov 2000, Alexandre Julliard wrote:
No, makedep relies on this to find out which headers to include in the
dependencies.
OK, I wasn't aware of that. Is this documented anywhere? (Not that I read
documentation, but... :) )
--
Dimi.
From: "Alexandre Julliard" [EMAIL PROTECTED]
Should we move ts_*.h and x11*.h to include/wine?
Well, some of these can go to dlls/x11drv I guess, but we first
have to move graphics/x11drv/* into dlls/x11drv. Would you accept
a patch to that effect?
However, some of the include/{ts_,x11}*.h
From: "Eric Pouech" [EMAIL PROTECTED]
may be we should have two different macros :
- SUBDIRS (only for recursion issues)
- SUBMODULE (as needed in WINMM/MMSYSTEM) case
I'd simply move all dlls in the dlls/ dir.
--
Dimi.
Log message:
Export the CallFrom16xxx functions from kernel32. Renamed them
__wine_call_from_16 to follow the naming convention.
...
+@ varargs __wine_call_from_16_word() __wine_call_from_16_word
+@ varargs __wine_call_from_16_long() __wine_call_from_16_word
+@ varargs
Indeed,
As James discovered already, the poblem seems to be the definition of
__ASM_GLOBAL_FUNC. Rest of Wine compiles OK. However, I have not been able
to get ld to generate dynamic libs on Cygwin. Did you guys solve this
problem?
(to compile Wine, I reenabled static linking for
On Thu, 16 Nov 2000, TAKESHIMA Hidenori wrote:
I don't know how to create .so on cygwin,
but if you want to create .dll, we can use dllwrap.
(DllMain must be provided for initializing dll.)
That's an idea. I don't know how difficult it would be though. I'll look
into it one of these days.
Hi Andrew,
I have several hacks in my tree right now that allowed me to _compile_
most of wine. The compilation still fails in the server and the comm
support. Now, the big problem is that I do not know how to get .so in
Cygwin, and as such the linking fails ATM.
In other words, we are still
On Mon, 20 Nov 2000, Andreas Mohr wrote:
- add winver settings nt2k, win30 and win20 (yes, some rare programs
^^
win2k would be better, maybe?
--
Dimi.
On Sat, 25 Nov 2000, Jon wrote:
On Saturday 25 November 2000 4:17 am, Dimitrie O. Paun wrote:
A lot more files do include them (more exactly 110), but they need not do
it. Should we remove the #include "config.h" in those cases?
I dont think so, since config.h may incl
On Sat, 2 Dec 2000, Eric Pouech wrote:
hypermail should be the "standard" mail interface
(www.winehq.com/hypermail/wine-cvs/ in your case)
(it *does* work for december commits)
Thanks, it changed and I was not aware to upgrade my bookmark.
--
Dimi.
This thread is becomming silly.
Sorry Patrik, but your arguments about heuristics are very strange. The
difference between a heuristic and an algorithm is that for an algorithm
one can _prove_ certain properties (such as big-O complexity, etc), where
as a heuristic has some interesting
From: "Ove Kaaven" [EMAIL PROTECTED]
I'm not sure if wineps is completely dll-separated yet.
BTW, do we have a list of dlls that are not yet dll-separated?
(I know, if we had, you'd know about wineps...:) )
Better yet, how can we tell if a dll is separated?
Would it be useful to create such
On Thu, Dec 13, 2001 at 07:47:42PM -0800, Alexandre Julliard wrote:
[snip] But I see now that there are
ways to make the code kind-of-proprietary that can actually cause more
harm to Wine than purely proprietary ones, and I think we should do
something to address this issue.
What do others
On Sat, 15 Dec 2001, Gerard Patel wrote:
At 07:47 PM 13/12/2001 -0800, you wrote:
What do others think?
I feel rather dismayed by the whole discussion.
Gerard,
Maybe this is so because the way you approached the issue.
See, you are concerned with the semantics of things, the 'why', and
I've initially wanted to reply to one of the messages in the thread, but I
realized that we're going in circles.
Let's recap, and look at the spirit (i.e. the intent) of the two licenses
in question:
1. BSD = here is the code, you can do whatever you want with it.
2. LGPL = here is the code,
On Mon, 17 Dec 2001, Roger Fujii wrote:
would be). And given that IMHO, a lot of wine work to be done
(looking at Direct* and other M$ stuff) falls under the unpleasant column
(ie, most people won't do this for fun), discouraging commercial work
doesn't seem to be the way to go.
And how,
On Mon, 17 Dec 2001, Patrik Stridvall wrote:
[snip technicalities]
Functionality on the other lies closer to fact or ideas than to expression
so I would consider it doubtful for the courts to extend the doctrine
of derived work to protect this.
Patrik,
The more I read your posts, the less I
On Mon, 17 Dec 2001, Patrik Stridvall wrote:
This has been my argument against Patrick exactly. Some
protection is better than none at all.
As a general rule, yes.
However this time the protection comes with a price.
And what might that price be? You fear that we are going to
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
You forget that some independent(*) parts like the Crypto API are
parts of other DLL:s (like ADVAPI32.DLL) for no particular reason.
This is ridiculous: it is one of the few exceptions, it is simply silly to
bring the Crypto API into this
On Tue, 18 Dec 2001, Roger Fujii wrote:
Dimitrie O. Paun wrote:
Technicalities aside, the LGPL spirit seems to be accepted by most people.
I have no problems with the 'spirit' of the GPL (or at least, how most
(ie, minus rms) people sees it).
Excellent. In fact, I disagree with RMS
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
Note that I said _small_ improvements because of the
modular nature of Wine. If the improvements are big, the DLL
separation would allow them to keep those changes proprietary.
I don't think small improvements is a problem anyway and
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
I'm against the fact that the GPL or to a smaller extent LGPL
tries use the doctrine of derived work as a weapon to achieve
their goals. It is a very dangerous weapon, since if the courts
or the policitians decide that a strong doctrine of derived
On Tue, 18 Dec 2001, Roger Fujii wrote:
lee wrote:
At this point, I would like to know if people agree up to this point.
Try reading section 2C of the LGPL and tell me how it's good for commercial
companies.
If LGPL is so clean, simple and nice, why does
On Wed, 19 Dec 2001, Patrik Stridvall wrote:
They had a goal and I'm sure a lot of competent people did the best
they could be accieve it.
However, you can do the impossible no matter how hard you try.
And this is precisely why your entire dissertation about the derived work
doctrine is
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
Sure it is true that what people (read: companies) believe is true is
more important than what really is true.
So, in fact, you indirctly agree that arguing about the doctrine of
derived work as part of this discussion is irrelevant.
All you seem
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
No, its not irrelevant because it will effect the advise the company
lawyers give their clients.
But know you are inconsistent with yourself. You've been claiming that it
is the very spirit of the LGPL that would scare companies away, and I can
see
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
Does it nessararily follow that you wish to accept any means to
achieve this? Including, say, to be really extreme:
Nuke the middle east, then it will be peace there
and after enough nukes it probably WILL be peace,
so it would be entire in line
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
In fact, choosing the LGPL is a very nice way of hedging our
bets agains
future changes in copyright law. And this is so because of
the negative
feedback loop that the LGPL introduces agains the copyright
law. Brilliant.
Now you are
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
There are many thing that are important in the world not just one,
so it was just a reaction of your persistance that the spirit of
something is the only thing that matters.
I focused on the spirit to put some sense in the discussion, go get to
On Fri, 21 Dec 2001, Marcus Meissner wrote:
Could we please create a new mailing list wine-license, where all the
people who care about licenses can discuss them?
Marcus,
I'm one of the few who are still discussing licensing, and I have to
apologize because I realize it is rather tiring.
It looks like we're running an old version of CVS on the server, as it
complains it does not understand
#cvs up -C
is it possible to upgrade it? That would be a good idea irrespective of
the -C problem, as the new versions fixed quite a few (nasty) bugs.
--
Dimi.
On Mon, 24 Dec 2001, Alexandre Julliard wrote:
hard, but I doubt you'll get gcc to generate exactly the above code;
and writing LdrAccessResource in assembly is not really an option.
Yes, but can't we write a trivial wrapper in assembly that simply calls an
internal function (written in C)
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
I personally think Perl would be a better choice, but I seem to be
pretty much the only one of this opinion. In any case the most
important thing is to choose something that people are going to use,
and so far the Perl stuff isn't a success in
On Tue, 8 Jan 2002, Ove Kaaven wrote:
Well, if random opinions count here, I also would prefer Perl. As much as
I hate Perl (I'm more in the Python camp), I'd hate writing regression
tests in C much more.
(Another Pythoner, cool :) )
But if we accept tests in C, we don't loose anything. If
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
The reason is very simple: WideCharXXX are Windows API, HEAP_strdupA/W
are not.
I have supported your effort for getting rid of the HEAP_strdupA/W calls
for this very reason: I strongly believe using the standard API is very
important for too many
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
Unfortunately that's not possible. If everybody uses his favorite test
harness we will soon have more of them than actual tests.
Certainly, I was exaggerating. However, we should accept tests written in C.
--
Dimi.
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
You can just as well put the inline functions directly into the C
file, or in some dll private headers. The functions are only 3 lines
long, it's no big deal to have a few duplicates. There is no reason to
pollute the standard headers with that.
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
That's just as much pollution. We must not introduce incompatibilities
except where there's clearly no other possibility. In this case there
are tons of other options.
If you insist... :)
Indeed. MultiByteToWideChar is just brutal IMO. But
On Tue, 8 Jan 2002, Francois Gouget wrote:
The perl test framework will need a way to build a zip file of some
sort with all the necessary stuff to run the perl tests on Windows. All
we need is for this to not be confused when we add the C tests. The C
tests will need such a functionality
On Tue, 8 Jan 2002, Gerard Patel wrote:
This has given me an idea - while I don't expect it to be
used in Wine, I will try to write my own test progs
with it : use the *windows* python interpreter under Wine.
From the doc, it's possible to call any win32 api from
it using a 'calldll'
On Tue, 8 Jan 2002, Alexandre Julliard wrote:
The W-A case is not a strdup, it's a simple WideCharToMultiByte.
Probably at least 90% of the existing calls to HEAP_strdupWtoA are
because of a W function calling a A function, which is precisely what
should be discouraged.
Good point. I'm
On Wed, 9 Jan 2002, Francois Gouget wrote:
That's true on Unix because sh, perl, and C executables will just
work. But if some of your tests are sh scripts you will have trouble
running them on Windows.
Yes, but nobody really proposes writing tests in Bourne-shell. In fact,
you can't
I've sent a message about the ListView control, and I can't see it in the
list's archives, nor have I received a copy of it, so I'm afraid something
happened to it, and hence this test message.
My apologies,
Dimi.
Hi people,
After a few more sleepless nights, I got the listview control close to
something I'm willing to submit. The patch is here:
http://www.cs.toronto.edu/~dimi/listview-unicode-2.diff
Last night I've sent a message to the list (including the patch), but I
think it didn't like it because
[once again, I attached the patch by mistake, and the mail did not go
through...oh well, that happens if you don't sleep at night:) ]
Hi folks,
Here is the latest version of the Unicode ListView control:
http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff
It fixes a silly (e.g. brown paper
OK guys,
This one fixes the bug found by Gerard (thanks a lot -- very good
spotting). You can find the patch here:
http://www.cs.toronto.edu/~dimi/listview-unicode-4.diff
This one can go to Alexandre, as far as I'm concerned. So if you still see
big problems, please let me know.
--
Dimi.
On Thu, 17 Jan 2002, Dmitry Timoshkov wrote:
I would suggest to explicitly use A and W suffixes to avoid confusion:
not just SystemParametersInfo, but SystemParametersInfoA.
For tests, I think we should in fact use SystemParametersInfo, and then
compile the test twice -- for A and for W. Both
On Thu, 17 Jan 2002, Alexandre Julliard wrote:
...and makes sure that the W functions are never actually tested with
Unicode input. It's not enough to simply pass converted ASCII strings
to the W functions, we have to test with real Unicode to check for
lossy W-A-W conversions, surrogate
On Fri, 18 Jan 2002, Andriy Palamarchuk wrote:
You definitely need #ifdefs or just unicode
conditional block around explicit calls of xxxW
functions. Otherwise these functions will be called on
platforms which do not support Unicode, even if test
application is compiled in ANSI mode.
Fine,
On Tue, 22 Jan 2002, Andriy Palamarchuk wrote:
--- Dimitrie O. Paun [EMAIL PROTECTED] wrote:
I have a number of observations:
-- we should rename wt_helper.h to something like
wine/tests.h
I'm open for suggestions. I used this name to avoid
name clashes with Perl winetest
On Tue, 22 Jan 2002, Alexandre Julliard wrote:
But we want people to think twice, and write a test adapted to the
function they are testing; you don't test ASCII and Unicode the same
way, except superficially.
With all due respect Alexandre, I can't understand your point. When does
the
On Fri, 25 Jan 2002, Duane Clark wrote:
That would be fine. It looked like a few pieces of the listview code
might still be needed, but definitely most of it is duplicated by the
recent changes.
Indeed -- I glanced over the patch myself, and it seems some things do
still apply. At the
On Fri, 25 Jan 2002, Bill Medland wrote:
Does anyone know how we (again) broke the text in the large icon display of
listview? It seems to come and go as we develop.
blushI probably broke it/blush
The symptom. Our application has a ListView window. As of yesterday's cvs
most of the
On Fri, 25 Jan 2002, Medland, Bill wrote:
Do you have access to the Microsoft rowlist sample? If so then use that
No, I don't. Can you send me a copy, or point me to a place where I can
get it from?
but edit a couple of the labels to be longer than one line. It's the being
longer than one
On Fri, 25 Jan 2002, Medland, Bill wrote:
p.s. what is going on in DrawLargeItem with the ellipsification; it looks
like it ellipsifies it and then throws the result away.
Bill,
Can you try the attached (uncompiled, untested) patch? It simplifies the
code quite a bit IMO. BTW, the previous
On Fri, 25 Jan 2002, Bill Medland wrote:
Fine (after satisfying the compiler).
Cool. What was wrong? Nevermind, I'll check the patch.
Shall I submit it or do you want the glory?
Sure I want the glory, but you can submit it. :)
--
Dimi.
On Fri, 25 Jan 2002, Bill Medland wrote:
Search at www.microsoft.com fpor rowlist; it's about the third hit
(msdn.microsoft.com/msdn-files). Download and compile under VC++ 6
That's great, but I don't even have a Windows partition, let alone VC++!
But nevermind the request, if the code
On Sat, 26 Jan 2002, Dimitrie O. Paun wrote:
[extracted from office2.diff]
ChangeLog
Tab Control: forward the notification message to the parent.
Oops, never mind this one, it's already in the tree.
--
Dimi.
1 - 100 of 1239 matches
Mail list logo
