Not portable items

[antonio]

Which items are definitively not portable from Delphi?

[Phil]

Which items are definitively not portable from Delphi?

(1) Automation, either to provide Automation server capabilities in your app or in using your app as an Automation client. COM Automation simply isn't cross-platform. You'll need to provide or use normal libraries (.dll, .so, .dylib) to communicate between programs.

(2) TRichEdit. This is a wrapper around a Windows control so it isn't portable. Depending on what you're doing with this control in Windows (editing RTF or just viewing RTF) there are probably several workarounds.

There are also some fairly minor differences from Delphi in both Free Pascal and Lazarus LCL that can generally be handled by conditional compiling (IFDEFs) in your source. Some differences may simply reflect that the corresponding LCL control isn't 100% finished yet.

If you have questions about specific controls or features of Delphi, that may be a better way of asking about portability.

[antonio]

OK. RichEdit isn't portable because it's a Windows control, because it's a wrapper or there's some not portable thing in the implementation? Which could be that?

(I'm trying to port an editable RTF control. No matter it could work only under Windows, I would like to port it anyway. I've received some error messages about pointers. Could it be this? If there are items on RichEdit which are definively not portable or there are workarounds, please tell me.)

[Marc]

the delphi TRichEdit control is a wrapper around the Microsoft Richedit Control. All RTF rendering is done by MS and not by Delphi.
So the TRechedit control isnot ported because it cannot be ported to other platforms than windows.

[antonio]

But it can be ported as a  Win32 component,  only for Windows? I have tried this and I have had some problems to do so. As far as I know, there's no reference about this. On my tests, it installs but doesn't work.

I'll try to port some Delphi components, so the portability issue.

[Marc]

We prefer to have a componentset for all widgetsets.

[antonio]

Isn't possible to port a control for Windows in Windows, another for Linux in Linux, etc, using {$ifdef}{$endif}, in a same component? If RichEdit is any way portable for Windows, could it be a starting point?

[felipemdc]

The problem is that there is a complete (or almost) richedit component on winapi, but there is nothing similar on Gtk. So on Gtk you would basically have to write the entire component from zero. And if you are doing that, why not writing the component only one time and have it cross-platform?

So, I think that any implementation of RichEdit for Lazarus will have to be based only on existing LCL and be written entirely, without using ready made things, like the rich edit control on windows.

[antonio]

You seem to be right, which is bad, Windows has also an HTML editable control. If there's some similar HTML on Gtk, or it could there be, please tell me.

Could it be made something with OpenOffice API? If true, the component would be plainly portable. Are there any references about that? Is there a working  Open Office component?

I thank to the time people spend to give help.

[Phil]

Could it be made something with OpenOffice API? If true, the component would be plainly portable. Are there any references about that? Is there a working  Open Office component?

I looked at this a couple years ago and as I recell OpenOffice has 3 API's: C++, Java and Automation. The Automation API is fairly straightforward to use (like MS Word's Automation server) but is Windows-only (and Delphi-only since Free Pascal doesn't support the creation of Automation clients yet).

To manipulate OO with Free Pascal you would need a procedural (non-OOP) interface. Not sure how much work this would require. Den Jean created a procedural interface for the Qt C++ classes but I'm not sure if this was automatically generated based on headers or hand-tuned.

I assume from your questions that you need a control that allows the user to enter rich text of some sort. If you only need to generate rich text (RTF or HTML) programmatically you can already do this with Free Pascal. If you only need to view rich text (RTF or HTML) you can easily launch Word or OO to view it.

Perhaps some more information about what exactly you're trying to do and why you want to do it that way would be useful for generating ideas and suggestions.

Thanks.

[antonio]

I'm trying to write or port components, specially those which are not present on Lazarus components palette and are very usefull under Windows.

Since TMemo control is a Windows common control too , I think I'll wait for its complete implementation before any decidings of WYSIWYG implementation. It will guide me about Windows API calls in this type of control.

Otherwise, Gtk has its own complete implementation. TMemo for Windows is also a wrapper (or should be), so I think Windows API calls for Windows TMemo implementation would be the best way.

Perhaps the same reasons could be valid for a TRichEdit or a THTMLite implementation, it would be RichEdit in Windows and a Memo in Unix. Or a TMemo control should be written from zero for the two platforms also.

Anyway, I would prefer an HTML based rich edit control for both platforms. SynEdit project would be near to do a cross-platform supermemo if it wanted. It could even become a new standard in editcontrols. If it wanted.