Wine Support for Rich Text Format

[generalhq]

I am a Windows Developer that is trying to get my program to work as well under Wine as it does under native Windows.

It's a big program, and I have almost everything working ok now. I was able to get around most of my problems already by making some changes to my Windows code. For example, I was having problems with double-click and drag/drop combo under Wine, but was able to solve that by moving my drag/drop logic to the OnMouseMove function instead of the OnLButtonDown function. With that change, drag/drop and double clicks work fine now under both Windows and Wine.

However, there is still more one thing that is not working that I can't figure out, and I was wonderring if anyone had a solution for me.

I have an RTF (Rich Text Format) window derived from CRichEditCtrl, and I can't seem to get any bitmaps into that window.

Doing it the standard Windows way, I got stimied by the fact that in Wine, the function OleCreateStaticFromData() returns an error code indicating that the function is not implemented.

So I tried another approach. I tried to get the RTF data for the bitmap into the control by using the StreamIn() function, but no joy there, either. For StreamIn() to work, you have to create an interface based on the type IRichEditOleCallback, and trying to create such an object in Wine causes an exception to be thrown. Arg!

I got both solutions for putting bitmaps into an RTF window to work under Windows, but neither one seems to work when the program is run under Wine.

So, my question is, is there any way at all to create an RTF window in Wine that will allow me to put my bitmaps into it?

I am ready, willing, and able to make changes to my Windows program to support Wine, if'n I only knew what to change it to.

Robert

[lahmbi5678]

Hi,

as a workaround for the Ole* issue you could try to override oleaut32.dll (maybe ole32.dll), i.e. copy Windows XP oleaut32.dll (ole32.dll) into wine's system32 folder and set an override in winecfg (native, builtin). Note that this is a flaky solution at best. It might help for the issue with IOLERichedit* issue to use winetricks to install Windows riched*.dll under wine, you may have to try different riched versions.

Please file bugs for all issues, i.e. OleCreateStaticFromData(), IRichEditOleCallback and the drag and drop issue, as it should be fixed in wine, too. It would really be helpful, if you create small demo applications for each issue and attach them to the bug reports. It may take some time, until a wine developer picks these issues up, please don't be disappointed, if the bugs aren't resolved immediately. On the positive side, there's currently some ongoing work in the OLE area, so it's not completely hopeless

[generalhq]

Thank you for the reply.

Before I even posted here, I tried using various versions of Winetrick's RichEdit support. I am currently using Richedit Version 1 (RichEd32.dll) and I even tried to change my code to use Version 2 (RichEd20.dll), with no luck.

On your advice, I tried to copy my Windows XP versions of the ole*.dll files to the wineskin's system32 folder and setting the override in winecfg (native, builtin). Still no joy.

As for the mouse issues with double-click and drag/drop, to be honest, I'm no longer worried about that one. It is clearly a bug in wine, but one I was able to work around in my code, by doing the drag/drop stuff in the OnMouseMove instead of the way Microsoft teaches programmers to do it on the OnLButtonDown. So now that my code works, y'all can take your time fixing wine so that it works for everyone else. lol

However, it sure would be nice to be able to see bitmaps in my RTF control.

I seem to understand from my reading of the forum here that trying to get wine to support the OleCreateStaticFromData() is not going to happen anytime soon. That is the 'standard' way of doing it. If you could get that to work, I'm sure not only me but many other people will be quite happy.

Barring a fix there, it would be nice to have an alternate approach of using StreamIn(). For a small test program that uses that approach, I would refer you to this webpage:

http://www.codeproject.com/Articles/954 ... s-and-Othe

If you can get the above small little demonstration program above to work, then I'm sure I could get my program to work, although the OleCreateStaticFromData() approach would be better.

You see, using OleCreateStaticFromData(), I could just store the BMP files for my bitmaps in my resources, and have the computer convert them to RTF for me, which would be ideal. That is the way my program currently works in Windows.

However, if you could get the StreamIn() approach to work as used in that demo program, then I could put in my resources not only the BMP files, but also an RTF representation of those BMP files (starting with a "{/pic" and having lots of hex digits, terminating with a "}") which I would then load and stream into the RTF control as necessary. My graphics DLL with all my bitmap resources is pretty big already, and adding an RTF version for all of them would probably more than triple its size, but if that's what it takes, I can do that.

I just need some method that will work in Wine. Any method.

[generalhq]

As Rosanna Anna Danna would say ... Never mind.

In the process of trying to mess with my wineskin configuration, to add various other RTF formats from WineTricks and copying Windows Ole DLLs into my System32 directory, I basically totally messed up my Wineskin to the point where it didn't work at all, giving me all sorts of errors and funky behaviors.

So I finally went back to our 'working' (albeit without bitmaps) Wineskin and tried it again, and lo and behold, it worked! Worked in that the little test program I gave in my prior post did work properly, and I was even able to put bitmaps into my RTF control using the StreamIn() function.

So, now I am confident I can make this work. I still have a bit of work ahead of me in order to write a program to convert all of my bitmaps into RTF format to add to my resources (in addition to the BMP files already there), but that is do-able. I am now confident I can make my program work well in Wineskin.

[lahmbi5678]

Hi,

as I said before, you really should file bugs for all the issues. It won't help you right now, but in the long run the issues need to be fixed in wine. Of course such a bug report only makes sense with some demo application. So it would be up to you to file bug reports. Please do not expect others to do it.

[generalhq]

ok. My project is now done and working.

For anyone interested, the project was to get Safe Harbor Games to work under the Wineskin Wrapper. SHG is a website at http://www.SafeHarborGames.net where you can play online multiplayer games, such as Backgammon, Spades, Hearts, Criibbage, Canasta, Euchre - that kind of thing. To play there, you have to download some Windows software. It was that software we were trying to make work under the Wineskin.

As of today, we have now released an Apple Mac Wineskin wrapper that works great for SHG, and for Linux users, posted directions on how we built the Mac Wineskin, assuming if they followed those directions, they should be able to build one for themselves, too.

The biggest problems we had in getting the Wineskin to work was the double-click/drag drop issue, which as I said before was solved by my moving the drag drop code to the OnMouseMove function instead of the OnLButtonDown function.

The second problem was the OLE support, not supporting the OleCreateStaticFromData function. I got around that by using StreamIn() instead. I originally posted this topic when I thought StreamIn() did not work, but it turns out it does if you have the proper RichText DLLs installed via WineTricks. The problem there is that StreamIn() assumes you have RTF data already, whereas using OLE will convert my bitmaps to RTF on the fly as necessary. My solution was to put two versions of the bitmaps in my graphics resource file, the original bitmap as well as the RTF representation of it. That did triple the size of my Graphics DLL, but since it's only downloaded once, that's not a huge issue, I guess.

The only two remaining issues we have now are very minor, having to do with IE. We use IE controls to display a couple banner and ad windows, and the Wineskin version always shows vertical scroll bars, even when no scrolling is necessary nor possible. The second issue is when we click a link at our site, I have code to determine the default browser, and invoke the link using that browser. That code does not seem to work, and the link is always opened with the Wineskin version of IE.

But other than that, the program is now running nicely under the Wineskin, and anyone interested in checking it out can now download the Mac Wineskin from the site and play the games that are available there.

Thanks for making such a great program to bring the Windows world to non-windows platforms!

[doh123]

The second issue is when we click a link at our site, I have code to determine the default browser, and invoke the link using that browser. That code does not seem to work, and the link is always opened with the Wineskin version of IE.

If you make the default web browser in the wrapper to drive_c/windows/system32/winebrowser.exe, it should launch the OS X default web browser correctly.

[dimesio]

Glad you got it working. Please note that Wineskin is not supported here, and any Wineskin-specific issues should be discussed on the Wineskin forum.

[generalhq]

If you make the default web browser in the wrapper to drive_c/windows/system32/winebrowser.exe, it should launch the OS X default web browser correctly.

Ok. I guess I wasn't clear.

If you click a link, such as a link that someone types into the chat, and let my C++ code open the link, it works great. It goes to Firefox or whatever your default browser is.

The problem is that we have 2 windows in our lobby that are actually internet control windows - basically little mini IE browsers in a window. We use those windows to show our ads, and they always use IE (or the Wine equivalent) to display. That's not a problem (except for always having the vertical scroll bars). The problem is if I click in those windows, unlike the 'Real' IE in Windows that will open up your default browser, the Wine version of IE will always open up a new version of itself, not the specified default browser.

[DanKegel]

I see your Wine page at
http://www.safeharborgames.net/downloads/aboutwine.php
Thanks for going to the trouble of posting that recipe.

I'll contact you off-board about the remaining problems.

[generalhq]

Thanks Dan, and everyone else, for your ideas and support.