Ok, so now that I've got the patch out, there's a weird problem that
I've been having with this piece of code. Apply the following on top of
my previous patch and you'll get the weirdest traces:
--- cut here ---
Index: dlls/comctl32/listview.c
===================================================================
RCS file: /home/cvs/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.99
diff -u -r1.99 listview.c
--- dlls/comctl32/listview.c 2001/02/28 05:31:02 1.99
+++ dlls/comctl32/listview.c 2001/03/02 23:45:09
@@ -1542,10 +1545,22 @@
item.stateMask = LVIS_SELECTED;
item.state = LVIS_SELECTED;
+ TRACE("nSelectionMark=%d nItem=%d nFirst=%d
nLast=%d\n",infoPtr->nSelectionMark,nItem,nFirst,nLast);
+#if 0
+ i = nFirst;
+ while (i <= nLast)
+ {
+ TRACE("i=%d\n",i);
+ LISTVIEW_SetItemState(hwnd,i,&item);
+ i++;
+ }
+#else
for (i = nFirst; i <= nLast; i++);
{
+ TRACE("i=%d\n",i);
LISTVIEW_SetItemState(hwnd,i,&item);
}
+#endif
LISTVIEW_SetItemFocus(hwnd, nItem);
infoPtr->nSelectionMark = nItem;
--- cut here ---
Now if I click on item 3 I get the following trace:
...
trace:listview:LISTVIEW_AddGroupSelection nSelectionMark=-1 nItem=3
nFirst=3 nLast=3
trace:listview:LISTVIEW_AddGroupSelection i=4
trace:listview:LISTVIEW_WindowProc hwnd=1908 uMsg=1006 wParam=0
lParam=405b6c30
trace:listview:LISTVIEW_AddSelectionRange Add range 4 - 4
...
Now, last I checked (i.e. a few minutes a go), 'for (i=3;i<=3;i++)
printf("%d\n",i);' prints 3 and certainly not 4. Also, if I'm not
mistaken this code is strictly equivalent to the while loop in the '#if
0' branch. Yet the while loop works fine but not the for loop.
In a word this looks like a gcc bug to me!
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)
How do we normally deal with those?
--
François Gouget
fgouget(a)codeweavers.com
I'm currently investigating moving all multimedia setup into the registry
as current WINMM/MMSYSTEM implementation is rather close to the WIN3.x/9x model, I started looking at their native implementation.
The main goal is to use no longer the hard coded drivers name, but rather get them from the registry
basically, it goes like this:
/*
* The Windows registry settings are as follows:
* - the drivers are defined by sets, each set has an index
* - the sets are loaded in the set index increasing order
* - a set is divided by classes (wave, midi...), and several drivers can be
* defined in each class
* - the keys are spread into two locations:
* HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\MEDIA\%idx%\Drivers\%class%\%name%
* where %idx% is the set index,
* %class% is the class (midi, wave...)
* %name% is the name of the device (which can be different from
* the actual name of a the driver's filename (even if,
* in lots of cases it's the same))
* these keys mainly describe what to load, and in which order
* This key shall also contain some configuration options for the driver (if
* needed...)
* - each entry under the Services\Class has a corresponding entry in another part
* of the registry
* HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\%class%\%namen%<%idx%>
* Under this location is stored information regarding how to load the
* driver (like if it's enabled, PnP information...)
*/
there are some other keys (like the PnP devices enumeration) which use the index to
refer to the driver
implementing this under Wine is not too difficult. The hairy part is the configuration (setting up the keys in the registry)
since the first step of the configuration (for this scheme) is to get the first unused index, this can be a bit tricky (especially
when a registry exists, and has been copied from a native one)
the possible solutions are:
A/ implement this mechanism and provide an ad hoc tool for this purpose. The hard part is, in some cases, that the data to add to
the registry have to be determined at installation time: the number of DSP available for the wave output, or the list of MIDI
playback devices (synthesizer, midi out...) - current WineOSS implementation gets its name from the kernel -.
A1/ create a specific (winelib) tool to take care of it
A2/ make use of Windows installation capabilities (setup API) and provide a .INF file for each. I'm not quite sure that's feasible
with the semantics of the API (mainly for the naming issue described above)
B/ do not implement this mechanism
B1/ provide a Wine specific easy set of keys
B2/ same as above, but upon startup, Wine (or winmm/mmsystem) partially recreates the native keys as needed
I'd rather go the A1 or B1. As of today, the only drawback of B1 is that some native DLLs (multimedia control panel, the midi
mapper) will not work. I haven't (yet) run against a program using this poorly undocumented set of features (which, of course, will
not work on Win2k with WDM in place).
any comment is welcome.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Hi,
With today's CVS I get problems with the Agent newsreader after 0.5 to
1 hour of use.
Sometimes I get this:
> wine client error:0x8063890: no fd received for handle 264
and the wine service tread has exited.
In other cases the program shows a message box showing:
cannor write <filename>. DOS error 4.
and the program goes crazy.
Dos error 4 means "too many files open", which seems related to the
first message.
Rein.
--
Rein Klazes
rklazes(a)casema.net
Hi,
I'm getting repeatable error's with the latest CVS version:
Protocol error:0x8066ae0: read : Resource temporarily unavailable
The application that is causing is the Gunman Chronicles Dedicated
Server. I tried to find out what is going on, but couldn't find anything
usefull.
Has anybody ales seen a similar behavior?
Andreas
--
-------------------- professional INTERNET services --------------------
EastLink GmbH Niederlassung Magdeburg voice: +49-180-5432060
Lorenzweg 42 fax: +49-371-4320626
D-39110 Magdeburg http://www.eastlink.de
