Hello to everyone who responded and tried to help!  I apologize for the delay in responding, I've been meaning to for a while now.  Because the issue we were experiencing was in a non-critical application we decided to work around the issue by sending any images as attachments.  Not the preferred solution, but we didn't want to put any more time into it by incorporating any 3rd party tools.

The one issue I was having with the new built in text control was resolved by registering the .dll.  I did not wind up needing it anyway, but again, I want everyone to know how much I appreciate their responses!

Happy holidays to all!  Be safe!

MJ

Hi MJ...not sure if you've found a resolution but wanted to touch base again. While some of this is a confirmation of what others have provided, this is my summary:

As Govinda stated, with the TX Text control used via an OLE control there is more functionality than Appeon has exposed (not advocating this approach, just drawing a comparison and it should be noted that to use this approach requires the full ActiveX version from Text Control for which the license isn't cheap). One of the key differences between that ActiveX version and what we have access to via the RTE control is that with the former you can pass a parameter, while you're saving, which indicates whether the image should be embedded in the file or saved with a reference/ link to the image file. With a RTE control it would appear that when you paste an image it, by default, will make a reference to a file (sometimes, but depends on the app you've copied it from, see exception below) and it's doing so incorrectly, per Miguel's comments and ticket 5954. It doesn't matter whether you do so via CTRL + V or use the control's Paste method, the result is the same. However, when you use the InsertPicture method it will, by default, actually embed the image into the file (using base64 encoding).

The developer doesn't have any choice with Paste/ CTRL+V or InsertPicture in terms of whether it is linked or embedded. The way the image is placed in the RTE control dictates what happens...usually. If you paste, it tries to link/ reference (and gets it wrong) or doesn't even place a img tag in the document. This was copying and pasting from MS Paint. However pasting the same thing from Paint 3D actually embeds the image, like it does with InsertPicture. Only when pasting from Snipping Tool will it actually place a img tag with the name of a tmp file which is no longer available, which may be what you want (in terms of placing an img tag, not the tmp file part). However you can't open saved images with Snipping Tool, only capture new images, so you couldn't use it as the intermediary tool to open an existing file, paste it and then manually correct the tag (not to mention the inconvenience of requiring these extra steps). No other image application that I tried placed the img tag in the file. Part of the above seems to reflect Miguel's experience too.

So, I'm not sure what your use case is and whether your users need to 1) be able to insert images via pasting or 2) be able to show the most current version of the image if changes were made to it, an advantage with linking or 3) be able to paste an image that has been saved, or one that has just been created/ captured but not saved anywhere, or both? If they are not requirements then you may be able to get around these limitations by using the InsertPicture method. Obviously this will also make your HTML files larger but maybe that would be the lesser of the evils. If you need to have images linked/ referenced, then you will likely have to resort to (I think) Miguel's method which is to insert the img tag programmatically (or modify the incorrect tag when inserted by an application that refers to a tmp file).

It's interesting to note that when you create a RichText file with another application, say MS Word, that has an image that was linked in it does include a link/ reference properly. But if you open that same RichText file in a RTE control 1) the picture does not display, just a box where the picture should be and 2) while the src img link/ reference tag is there the value is wrong (once saved as HTML) so something is getting lost in the translation.  If the MS Word generated RichText file has an image embedded in it the RTE control seems to be able to display that fine as well as save as HTML fine.

Hopefully I haven't confused you more and not sure the above has helped much, maybe so if InsertPicture is an option for you.

I agree with Miguel that the RTE control is problematic in it's current form as it relates to pasting images. Hopefully this will be corrected/ improved soon but the ticket that was entered for this issue doesn't seem to be aging well :-(

Regards,

Mark

Hi:

Somehow my latest reply never seems to have made it to you, so I am going to try again.  :-(  

Mark, your comment "Maybe what is being misunderstood or not realized is that both the RTE Control approach and the OLE approach are dependent on the same TX Text Control 28.0...see pic below from the OLE tab in the Object Browser" is spot on.  Thank you for that clarification.

Rather than fighting my code, @Miguel, I used your example.  It is saving as an .html document now, but it is not saving the .png files to the same directory (or in the standard asset directory).  It says it is saving it to my AppData\local|Temp directory.  I remember reading something about that during all my other research and for the life of me I cannot find that same conversation that I believe was on the Appeon Community board.  Suggestions?

Thank you, really!  The response has been fantastic.

MJ

Hi MJ,

Please forget about the video you watched and trying to do things by inserting an OLE object, just use the RTE control and specify the v28.0 version in the properties of your application object.

Yesterday, I attached a working very simple sample application to your question on https://community.appeon.com/index.php/qna/q-a/how-to-use-the-new-built-in-tx-text-control-in-pb-2019-r3-2703 just in case you didn't see it.

Hope it helps.

Thanks for the additional information MJ. Some more thoughts...

Since you now have the TX entries showing up when you try and add an OLE control, I would first re-try adding the RTE control and see if that now works. Again, it feels like the issues of not being able to utilize a RTE control or OLE control previously are related and so maybe both are now resolved.

Some of this is a repeat but please bear with me....Govinda's video starts talking about the RTE control enhancement at 25:32; there he discusses, for PB2019R2, the difference between a 32 bit app, that uses the TX Text control, versus a 64 bit app which uses the MS RichEdit control and he talks about the big differences between them. Then he talks about how in PB2019R3 the TX Text control is now available for a 64 bit app, no longer requiring the MS RichEdit control. It's at 30:11 that Govinda starts to talk about using the OLE control to take advantage of additional features not yet exposed by Appeon when utilizing the RTE control. This is what is apparently not supported by Appeon yet, per Chris. However, all the functionality you are looking for, I believe, is available when using a RTE control based upon the TX Text Control 28.0, regardless of a 32 bit or 64 bit app. As for the RTE control failing for you, I think that is failing for a different reason and is coincidental to the documentation, especially since the failure the documentation is referring to is the MS RichEdit control, not the RTE control based upon the TX Text Control 28.0. Yes, the result is the same, a return of -1, but I believe for a different reason.

Andreas can correct me if I'm wrong, but I think what he was referring to was using the SaveDocument method via the RTE control (as I'm using it), not using the same TX Text Control 28.0 in an OLE control. Just to restate...Andreas is not using the OLE approach, he's placing a RTE control on the window and it's working...both 32 bit and 64 bit.

Maybe what is being misunderstood or not realized is that both the RTE Control approach and the OLE approach are dependent on the same TX Text Control 28.0...see pic below from the OLE tab in the Object Browser.

If the RTE control still doesn't work for you then maybe you're at the point of opening a ticket with Appeon or trying a re-install as this should work.

I would have provided this reply in a comment under your response to me, just to keep it all in one thread so as not to make it more difficult to follow, but unfortunately we can't paste pictures in a comment.

HTH...regards,

Mark

Hi Mark:

I would be happy to clarify :-) 

1.  Yes, we are starting to build all of our applications as 64bit.  So far this is the only real problem we have experienced.  And yes, my research lead me to believe the only way I can successfully save a document/image as .html was using the new built in TX Text control as OLE.  I hope I stated that right.  Part of the confusion is OLE objects are new to me.  

2.  We tried this in the RTE control and it failed, and it failed exactly how the documentation says it would.  And the same documentation says the TX Control would work.  But, the TX Control didn't work because I wasn't able to insert it.  Late yesterday I followed John Fauss' instructions to register a certain .dll and now I can see those controls in the dialogue box.  But I haven't tried anything else yet and some of the follow up emails I received last night and early this morning indicate I shouldn't because the TX Control is not OLE certified, thus not supported. 

I need to spend some time reviewing all of them and get it all on paper, because you are right, all the emails have added to the confusion, but only because there are so many different thoughts and they show up in different areas.  I am not complaining one bit - the response has been tremendous so I am happy to do it!  

Chris asked me to show the old PB2017R3 code that creates the XML and the 'internal' source code for the TX(RTE) being used, so I will be replying to him soon too.  Miguel states the export to html has quite a few bugs but is slowly getting better.  And I've reviewed those, but the video lead me to believe that the TX Text Control would work so that is why I tried to go down that path.

Andreas also pointed out the same documentation I did about the SaveDocument supporting .html in the TX Text control, and has used it to convert doc and docx to html, but if using it that way isn't supported I need to pause and think through this.    

Thank you!

MJ

Also I want to add that the following part of PB's help file:

Hi to everybody in this thread.

We do have an application using built-in richtext control (v.28.0).

We do store contents in richtext control using copy paste, and save them using:

rte_doceditor.savedocument(ls_path, FileTypeHTML!)

This works fine for us on both x32 and x64 executable. We are able to see the produced html using web browser control. The whole application is based on that concept. We had some stability issues with webbrowser control, and we found that TX richtext edit v.28.0 has some issues (some times we get a garbage "a" I think it happens after udno) and we had issues with pasting images. But no problem with our application saving in html when compiled as x64.

Follows a screenshot with an html containing part of Appeon Powerbuilder new features. You see an html file in a webbrowser control. Html was saved in an x64 pb application (it's the same on that shows the following window). We use TX Text Control ActiveX 28.0 (the built-in one).

The control was added to a window using the procedure that John Fauss already described.

Here is the window from the x64 application showing the content we saved as html (copy paste from PB Help File).

Andreas.

Hi MJ,

My apologies for potentially adding more confusion to your issue as there have been many good responses in trying to shed some light for you. Sometimes when you receive so many they can be hard to follow, so at the risk of making it worse, I do have some questions:

1) There may have been some assumptions that you are trying to build a 64 bit application but is that actually the case? Or maybe you're trying to create a 64 bit app because you believe that's the only way to get the TXText control or OLE approach to work?! The reason I ask is because you haven't stated this anywhere, unless I missed it, that the app must be 64 bit and you stated that "PBNative RTE was working in PowerBuilder 2017 in a 32 bit exe". So maybe from your post at 17:36 where you talk about the SaveDocument no longer working and provide a link (and then a screenshot) which compares the MS RichEdit (64 bit) to TX Text Control 28 (64 bit) and the former not being able to SaveDocument as a Doc, HTML or PDF type it was implied you are trying to create a 64 bit application. Again, in your post at 20:59 you refer to the SaveDocument issue as a limitation but the limitation is on the MS 64 bit control, not on the TX Text control that Appeon provides.

2) Were you trying to accomplish this via an OLE approach versus a RTE control because you thought the latter doesn't work due to the same reason as above in 1 or did you actually try it and it failed? If you tried it and it failed then I think it may have failed for the same reason you can't see the TX entries when inserting an OLE control and so whatever is going on maybe has buggered up both the TX Text Control and the ability to see it in an OLE control. Or, did the TX Text Control approach work for the most part but you weren't able to save multiple images as one file which I think you mentioned was also a requirement?

I haven't had time to try and see if the OLE approach works for me (and maybe it's irrelevant if Chris says it wouldn't be supported anyway) but in one of my applications I am already using the TX Text Control ActiveX 28 and can successfully SaveDocument in the format of Doc, HTML and PDF (albeit in a 32 bit app and have not compiled it as a 64 bit app yet but will give it a shot when I have time and if you haven't found a resolution yet and it is in fact a 64 bit app that you need).

Not sure if I've added any clarity or simply provided more fog but curious as to your answers MJ. Thanks.

Regards,

Mark

Hi MJ;

   That still does not make any sense for PB2017Rx releases as the internal TE or TX "built-in" control in that version is "internal". Thus, you would not be adding / using it as an OLE control. Neither would you see it listed in the O/S list of "insert-able" controls. The only way that wold occur is if you have a direct copy of the TX control from the software vendor (not Appeon).

   Remember that the "built-in" TX Control has reduced functionality than the purchased (aka Enterprise TX control) from the TX software vendor.

The best would be to show us the old PB2017Rx code that creates the XML and the "internal" source code for the TX (RTE) control being used.

Regards ... Chris

Hi Chris:

Let me back up.  The PBNative RTE was working in PowerBuilder 2017 in a 32 bit exe.  We JUST upgraded to PB 2019 R3 2073 and the SaveDocument as a FileTypeHTML! does not work.  It is listed as a 'limitation' in the documentation and will Return a -1 when trying to save as .pdf or .html.  We are not using a purchased version of the TX control because PB 2019 R3 includes it.

We need to be able to save multiple images to 1 file, and that is why we are saving them as .html and why I need to continue saving them as .html.

 PB documentation recommends using the Built-in TX Text Control ActiveX 28.0 and shows where it can save as .html & .pdf files.  This is what I need.

I have followed the directions according to the documentation to point to the Built In TX Text Control.

The video says the built in version in R2 is limited, but he compares it to the R3 version in which he shows us the ability to save a document as .pdf (and according to the PowerBuilder 2019 R3 documentation it will do .html as well).  He also shows us how to add the OLE object to the window, and that is where it says I should be able to see the TX options. 

It is possible that I am misunderstanding something, if that's the case, please help me see it.  It wouldn't be the first time I've missed something.

Thank you so much!

MJ

I had the same experience as you. With a little research, here's how I was able to get those items listed:

1. Click on the Windows/Start taskbar button (left-most taskbar icon), type "command", then click on "Run as Administrator" (even if you are an Administrator).
2. User Account Control will ask to verify. Click on the "Yes" button.
3. The command prompt window will open. The path should be C:\Windows\System32".
4. You need to register the TX 28 ActiveX control (ocx). It resides in the PB 2019 R3 runtime folder. On my system, here is the command I used:
   
   regsvr32.exe "C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.0.2703\tx4ole28.ocx"
   
   
5. Exit the command prompt via the "exit" command.
6. Restart PB 2019 R3.

When you add an OLE control in the Window Painter, you should see those four "TX" objects listed.

HTH

Hi MJ;

  I see your problem (I think) in that when you try an OLE Control insert, you do see the TX control in the insert dialogue ...

   In the native PB's IDE built-in TX control you would not see any TX Control registered in the O/S like you do see (as above). So IMHO, you have a "Purchased" version of the TX control. The purchased versions of the TX control have way more functionality than PB's built-in one. That would explain when you tired the save the RTE/RTF text to HTML was working before OLE wise but not using PB's built-in one. The version of the TX control Appeon gets from the vendor has less functionality than the purchased one.

   BTW: If you do go back to a newer purchased TX control to gain back the extra functionality, you do not need add the control via OLE. In stead, you can use the PB IDE's Application Painter for that, as follows:

HTH

Regards ... Chris

MJ - Is the problem you are experiencing that you do NOT see the four "TX" object types in the OLE Insert Object dialog that are highlighted in the screen image included in your original post?

MJ,

I do see them listed with pb2019 R3 build 2703. So ... I think you should create a support ticket on https://www.appeon.com/standardsupport/newbug as it seems to be an installation problem.

It's a shame though that Govinda doesn't really show how he inserts the control. (he clicks on the cancel button). When I click on OK, I'm immediately being prompted to insert something else. (I guess I should cancel at that point, but I'm not sure).

Hi John:

The standard rte in PB 2019 doesn't allow me to save attachments as .html.  In PB 2019 R3 2703 an OLE Text Control feature was incorporated into the release that should allow my application to continue to do that.  That is the one I need.

Thank you for the timely response, but I need help with the new TX Text Control feature.

MJ

Hi, Mary Jane - 

I'm not a RichText-savvy person, but if you are referring to adding a RichTextEdit control to a window, then I think you want to place a RichText control on your window instead of an OLE control.

Here's what the RTE control selection toolbar button looks like in the Window Painter in PB 2019 R3:

HTH.

Best regards, John