[Bug 4195] New: apparent mishandling of RichTx.ocx

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=4195

Summary: apparent mishandling of RichTx.ocx
           Product: Wine
           Version: 0.9.4.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-misc
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

The problem occurs while trying to load GURPS Character Assistant.  A program 
put out recenlty by Steve Jackson Games (sjgames.com).  The program is written 
in Visual Basic. As it's been difficult pinning down the source of the issue 
even with the programmer of the software's help I must be extremely thorough for 
fear of missing anything that would make sense.  When trying to run the program 
in various flavours of wine (cedega 4.2 & 5.0, CXoffice 4.1, Wine Debian etch 
default/winehq 0.9.3+) various errors occur that amount seem to be related to 
the richtx.ocx file, either that the version of that file seems wrong and that I 
should use the one that comes with the software (oddly enough, that's exactly 
what I was using) if using Cedega (I know that has its own support, but I feel 
it should be mentioned in case it gives insight as it is a spin off app), the 
actual software reports (or perhaps the "windows" error handling, I wouldn't 
know which) that there is an invalid property value (pre 0.9.3 wine and 
cxoffice), that there is a subscript out of range in 0.9.3+.  These errors occur 
while the software is initializing.  When first run the program opens a Logging 
dialog box to show what it's doing.  With the property value error will display 
the version of the software (as it should) but then displays one of the 
mentioned errors the area between printing version number and the next line of 
the logging box, the program isn't doing anything (see Running on Linux thread 
of forums.sjgames.com in forum RE GURPS Character Assistant).  The other errors 
occur trying to form the Logging window (Cedega) or just after forming it before 
printing the version id.

the output that wine is feeding back in the terminal (the only debugging info 
specific to wine I can find.. sorry, I haven't figured out wine-dbg it just gave 
me a funny prompt I couldn't get out of w/o using ctrl-c):

fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx (0x7e285b04,774,0,{7bf80980-bf32-101a-8bbb-
00aa00300cab},x=0,y=0,f=0,0x7fbff978), partially implemented.
fixme:richedit:RichEditANSIWndProc EM_SETOLECALLBACK: stub
fixme:richedit:RichEditANSIWndProc EM_GETOLEINTERFACE 0x7fdbd380: stub
fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub
fixme:richedit:RichEditANSIWndProc EM_SETTARGETDEVICE: stub
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
fixme:richedit:RichEditANSIWndProc WM_STYLECHANGING: stub
fixme:richedit:RichEditANSIWndProc WM_STYLECHANGED: stub
fixme:ole:OLEPictureImpl_SaveAsFile (0x7fdb71a8)->(0x7fdc4038, 0, (nil)), hacked 
stub.
fixme:richedit:IRichEditOle_fnInPlaceDeactivate stub 0x7fdbe838

I've noticed that usually when any of the things on the forum discussing this 
mention the wine output it is primarily richedit and Richtx that come up most 
often in the output, hence a feeling that perhaps that and wine's ability to 
deal with it being the cause of the program not running.  Though I'm also the 
first to admit that I can't program in anything more advanced that QBasic, so 
I'm probably wrong.