wine-devel May 2003

wine-devel@winehq.org

123 participants
270 discussions

CTRL-C in winedbg
by Gerhard W. Gruber 24 May '03

24 May '03

I tried to set a breakpoint in agent when I investigated that crash. Since the address was not available at start I fired up Agent and then used <CTRL>-C in winedbg afterwards. The problem I had with this is, that this doesn't seem to be transparent to the application. Most of the time Agent crashed with unhandled exception when I continued. I thought that pressing CTRL-C shouldn't be noticable for the debugee. Of course there could be code that could make problems like timer or such, but I don't know if this is the case here. I tried this several times and only two times it worked as expected. All the other times Agent crashed. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

2 1

XFS may support case-insensitivity soon(ish) & lufs does it now
by Russell G. Howe 24 May '03

24 May '03

I noticed on the linux-xfs list an announcement by Steve Lord where he listed a few things which might make it into XFS in the next few months: http://oss.sgi.com/projects/xfs/mail_archive/200305/msg00233.html One of them, "Mixed case support in XFS (for Samba)" presumably means case-insensitive filenames/directories. Keith Owens also mentioned the lufs (Linux userland fs) project at http://lufs.sf.net/ This apparently allows for case-insensitive filesystems by way of a userspace wrapper. For anyone who might be having trouble with case-sensitive UNIX filesystems, these might be worth considering. Note that I haven't tried lufs, and the XFS stuff hasn't yet been released, but maybe the information is useful to someone. -- Russell Howe | Why be just another cog in the machine, rhowe(a)wiss.co.uk | when you can be the spanner in the works?

1 0

Winedbg backtrace
by Gerhard W. Gruber 24 May '03

24 May '03

I spent the last few hours trying to debug Agent. I was setting breakpoints on the last function and wondered why this breakpoint is not triggered before the crash occurs until I finally realized that the backtrace is upside down. Is it intentional that this is the case? Also I wondered if it wouldn't be better to show the register dump after the trace. If the trace is very long (I guess this could be the case rather often) then you always have to scroll up or type "info reg" in order to get the dump. At least I think I may make more progress now that I know that I was always looking at the wrong function because of the order. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

2 1

Help with dlopen and friends
by Shachar Shemesh 23 May '03

23 May '03

Hi all, I am trying to add ICU as a soft dependancy of Wine, so I can use it's BiDi functions. Unfortunetly, it seems to be using miracolous name mangling. ubidi.h has: U_CAPI UBiDi * U_EXPORT2 ubidi_open(void); however, 'nm -D libicuuc.so.21.0' gives: 00046784 T ubidi_open_2_1 The problem is not just theoretical. When I try to add to configure.ac: AC_CHECK_LIB(icuuc,ubidi_open,icu_lib=yes) the resulting program does not compile. It only compiles properly if the original header is used (I presume because that's how it knows about the name mangling). My dillema - even if I sort the configure mess out, for example by telling it to compile my own program, that uses the proper include, I am still not going to be successful in importing the symbol. As it appears that the mangling is a simple append of the library version, I can do this manually, but then future version stand no chance of working. Even if a simple recompile would solve it, the version will need to be updated at the import code. Possible solutions: 1. Use a different library - can be done, but messy. This is the most apropriate tool for the job. FriBiDi doesn't have shaping support, so Arabic will not work properly. 2. Inline the entire library - huge, and a maintanace headache. 3. Reimplement everything - possible, but seems like a total waste just because of a stupid name mangling. 4. Create a hard dependancy - not really an option. 5. Static link the library - now that will actually work. It is equivalent to 2 without the maintanance headache. Opinions and thoughts, please. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

7 13

load_dll problem
by Dimitrie O. Paun 23 May '03

23 May '03

Folks, I am trying to run some Winelib apps built with winegcc, and they don't work. winegcc/winewrap do the wrapper idea to avoid initialization problems: basically the main app is built as a .dll which is loaded with LoadLibrary by a small loader. Well, this DLL is not found, and the app doesn't load. I think the problem is in load_dll(), in dlls/ntdll/loader.c line 887: if (!libdir || allocated_libdir) found = SearchPathA(NULL, libname, ".dll", MAX_PATH, filename, NULL); else found = DIR_SearchAlternatePath(libdir, libname, ".dll", MAX_PATH, filename, NULL); As SearchPathA doesn't seem to know that it also needs to look for the .so version of the DLL. Here is what happens: 1. Directory contents (simplified) [dimi@dimi dialogs]$ ls CVS dialogs.def dialogs.h dialogs.pro descrip.mms dialogs.dll.so dialogs.ico dialogs.rc dialogs dialogs.dsp dialogsM5.xml dialogs.rcO dialogs.cpp dialogs.exe.so dialogs.o dialogs_resources.o 'dialogs' is a small bash script which loads 'dialogs.exe.so' which does a simple LoadLibrary('dialogs.dll') to load 'dialogs.dll.so' which is the actual application. 2. Here is the relevant part of: ./dialogs --debugmsg +dosfs,+file,+module,+loaddll with a 'grep -v trace:dosfs:DOSFS_ReadDir' for brevity. trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:dosfs:DOSFS_GetFullName L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi" trace:dosfs:DOSFS_FindUnixName (/home/dimi,L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll") -> L"dev" (L"DEV") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev,L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev,L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll") -> L"wine" (L"WINE") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine,L"wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine,L"wxWindows\\samples\\dialogs\\dialogs.dll") -> L"wxWindows" (L"WXWI~MP0") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows,L"samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows,L"samples\\dialogs\\dialogs.dll") -> L"samples" (L"SAMPLES") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples,L"dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows/samples,L"dialogs\\dialogs.dll") -> L"dialogs" (L"DIALOGS") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs' trace:dosfs:DOSFS_GetFullName L"dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1da8) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs' trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows' trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:dosfs:DOSFS_GetFullName L"c:\\windows\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows' trace:dosfs:DOSFS_GetFullName L"c:\\windows\\system\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\system\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\\system\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\system\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"system\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\\dialogs.dll") -> L"System" (L"SYSTEM") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' trace:dosfs:DOSFS_GetFullName L"e:\\\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/tmp" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/tmp' trace:dosfs:DOSFS_GetFullName L"e:\\test\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,L"test\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"test\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/tmp" warn:dosfs:DOSFS_FindUnixName L"test\\dialogs.dll" not found in '/tmp' trace:dosfs:DOSFS_GetFullName L"f:\\\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi" trace:dosfs:DOSFS_OpenDir "/home/dimi" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi' trace:module:MODULE_GetLoadOrder looking for C:\WINDOWS\SYSTEM\dialogs.dll trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:module:open_app_key searching 'dialogs' in AppDefaults\dialogs.exe\DllOverrides trace:module:MODULE_GetLoadOrder got standard wildcard "b,n" for "dialogs.dll" trace:module:load_dll Trying built-in 'C:\WINDOWS\SYSTEM\dialogs.dll' warn:module:BUILTIN32_dlopen cannot open .so lib for builtin dialogs.dll: /usr/local/lib/wine/dialogs.dll.so: cannot open shared object file: No such file or directory trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\dialogs.dll' trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" GENERIC_READ FILE_SHARE_READ OPEN_EXISTING attributes 0x0 trace:dosfs:DOSFS_GetFullName L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\\SYSTEM\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"WINDOWS\\SYSTEM\\dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\\SYSTEM\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"SYSTEM\\dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\\dialogs.dll") -> L"System" (L"SYSTEM") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" (GLE 2) warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\dialogs.dll'; status=-1073741809 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 -- Dimi.

6 21

Overlapped I/O + hEvent == NULL reopened + other questions
by Thomas Charbonnel 23 May '03

23 May '03

Hi, I'm trying to migrate a proprietary TCP/IP client/server db application from Windows NT to Linux using Wine, and am encountering some difficulties. * First of all the application uses overlapped I/O in an unconventionnal way. The application scenario is as follows : Setup server socket Call WSAAsyncSelect On accept, create a new window associated with the new socket Call WSAAsyncSelect for this new socket/window. On network event on the new socket, if the FD_READ event is passed to the WindowProc, call ReadFile with an overlapped struct, but hEvent == NULL On IO_PENDING_READ_ERROR, call GetOverlappedResult with bWait set to TRUE There was a thread about this on this list on November 2002 ("Overlapped I/O without an hEvent"). At that time Martin Wilck submited a patch that did not get commited to CVS. I got things working by slightly modifying his patch. The idea was floating around in the November thread : in the GetOverlappedResult function, if the bWait flag is set, then wait calling WaitForSingleObjectEx with the socket handle passed in instead of the overlapped structure handle. I suspect this method is unclean, but works for me as the server app I'm trying to run instantiates a window (thus a WindowProc) per client. I'm waiting for your comments and suggestions on how to properly handle this. * Next I have a problem with high network loads (maybe related to the previous issue). When I run the sever app in Wine and access it with a remote client, operations generating a high network load tend to be unstable. Most of the time the client application hangs at some point, and sometimes the server hangs too. This does not happen if I run the client with Wine on the same machine as the server. Are they known issues with the winsock implementation ? * Wine used to crash because the server app called WritePrivateProfileString with a NULL lpFileName. I fixed this by returning FALSE if lpFileName == NULL, but I don't know how windows handles this. The app calls WritePrivateProfileString with a proper file name a couple of times before setting it to NULL, so I suspect windows is caching the file name. * The client comes with a printing helper app. They communicate through dde. I get the 'fixme:class:get_class_ptr reading from class of other process window' message. How is this supposed to be handled ? * Minor remaining problems : - the end of tooltip texts is garbled - help doesn't work (it seems the help file name is not passed as a parameter) Thanks for your attention, Thomas

3 2

A under-educated question
by Steven Edwards 23 May '03

23 May '03

Hello, I am going to attempt to split commdlg and comdlg32 in to win16/32 parts and am having trouble with all of the internal functions. How can I export a function from one object to another? I have tried declairing the internal functions in a header and its still not working. Forgive me I am still new to this. Here is a mini-example of what I am talking about. fubar32.c /********fu internal function*********/ void fu() { do stuff } /*******Bar[A/W] Win32 function*******/ STDCALL BarW() { fu("importing fu in to barW\n"); } Next I have a Win16 function that needs to import fu. How can I export it? fubar16.c and then in the win16 file we import the fu function/ /************Bar16***********/ PASCAL bar16() { fu("importing fu for Win16 function"); } Thanks Steven

2 1

Fw: Re: [latest cvs] Yet more GTA3 errors.
by erwin wolff 22 May '03

22 May '03

Hi, Thanks for the device.c. GTA3 still crashes in a fatal exception when starting a level ;(. But this time it produces an other error than before :) : fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402a5380)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), AdptFmt:(23,D3DFMT_R5G6B5), Use:(0,none), ResTyp:(3,D3DRTYPE_TEXTURE), CheckFmt:(41,D3DFMT_P8)) fixme:d3d:IDirect3DDevice8Impl_SetPaletteEntries (0x402e5e70) : setting p[41] <= RGBA(00,00,00,ff) fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. wine: Unhandled exception, starting debugger... At the ingame menu it produces this fixme: fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette >>>>>>>>>>>>>>>>> 500 from glColorTableEXT @ device.c / 4437 fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402e5e60) : Setting to (48) fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette >>>>>>>>>>>>>>>>> 500 from glColorTableEXT @ device.c / 4437 The menu textures still don't look nice but it is much better than before :). If you want a screenshot, just ask. --------------------------------------------- erwin wolff erwinwolffnl(a)microformatica.com

2 1

-fexceptions? -fasync-unwind-tables?
by Gregory M. Turner 22 May '03

22 May '03

OK, as you may have guessed, I'm still driving myself insane trying to fix __try and friends. I have some other less promising ideas on the backburner; this one seemed to have sufficient potential that I thought I would ask the group to let me know what they think. In short: gcc accepts the above options. The first, is considered to be a C++ compatibility mode in C. That is to say, it provides the right glue such that exceptions can unwind through calls to C libraries. If /any/ library in the call-chain leaves this option out, I'm afraid it breaks down. The second, -fasync-unwind-tables, provides "dwarf2 unwind tables". I've looked through the dwarf2 spec and some other sources, but I have yet to find solid documentation for this... perhaps it's a "use the source, Luke" situation. But this second option promises "instruction-granularity" unwind tables of some kind. IOW, presumably, this would be enough to implement __try and friends without looking beyond the stack pointer. As for the idea of stealing the return pointer on the stack. I like it even less now. It appears that signal handlers are allowed to clobber the stack above the SP on some architectures, which means we're pretty much up a creek. There still might be some ultra-clever work-around involving copying the current stack frame, but I think we would at least have to create our own trampolines in asm, which, I fear, might break in subsequent gcc releases... So... anybody know where these options are actually documented? I mean, I see the blurb in the info pages, which is enticing, but surely there is some API or datastructure to look at somewhere.... -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

4 7

TAB doesn't work for controls anymore
by Gerhard W. Gruber 22 May '03

22 May '03

Since a few days I noticed that you can't use TAB anymore to cycle through controls. I noticed that when using Forte Agent, because I can't use the keyboard to switch from To: to Subject and so on. Any ideas what has been changed? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

8 18

← Newer
1
...
5
6
7
8
9
10
11
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2003