Is anybody else having an issue with generating text on the text translation field when developing an HTML Form? I'm concatenating a string together in my Javascript and I'm using the $window.external.SetTextTranslation() method to display the text. I have it to work on my machine because it's using an older version of CPS, however in Centricity's latest version it seems to not be generating the text at all.
Anybody have any ideas as to why this is happening?
Thanks.
Matthew, the issue is with GE's library. I think the issue was introduced in version 12.2. I discovered this several months ago and I have been told it will be corrected in version 12.3. I am curious to know what tools you are using to develop your HTML forms. I am currently using Clinical Forge and the developer of this tool has incorporated a "fix" until GE corrects the issue on their end. I would love to speak to you offline about your development experience as there are very few of us out there that are developing forms in the new format. Perhaps we could meeet up at a CHUG at some point. Shoot me an email if you are interested in having a conversation.
I would be interested in learning more about HTML development. I have not made any forms in the new format, but I have some experience in HTML/CSS/JavaScript, and would love to learn the best way to use it in CPS.
I'll be at CHUG as well if there is a group meeting up. 🙂
Thank you,
Daniel C.
Unfortunately I will not be at CHUG this fall, but do plan on going to Centricity Live in the spring since it is closer to home (Nashville). I'd be happy to set up a telephone conversation so that we can share experiences. Shoot me an email and we will make it happen.
Hey Matthew,
For the new embedded HTML forms, I use the following API call instead:
window.external.SetChartValue(document_variable, text_translation)
When you import your HTML form into Centricity, it will default your form's document variable to DOCUMENT.TEMPHTML0_FORMID. Where FORMID is the FSID of you form in the FORMSET table. As you reach 4000 characters, it will create DOCUMENT.TEMPHTML1_FORMID and so on. You can get the form id calling the global variable window.external.FormId. Be careful when you call this, though. If it is called during window.unload() and the user clicked on another HTML form in the encounter, it will actually pull the FormId from the other HTML form. That will make this form's text translation print out under the other HTML form :-).
Another thing to keep in mind is that SetChartValue will encode }, {, ", :, ,, and ' with their HTML encoded equivalents. The 2 ways I get around this are adding some replacestr() functions to the table where the form's Document variable is stored to decode everything, or you could not use the embedded form's document variable and write to another document variable in one of your other forms or a text component. The latter is how we handled text translation before the forms were embedded.
Let me know if you have any questions.
Hey Mike,
I was able to solve this roadblock and for the past few months I've been using the window.external.SetTextTranslation function still, which has worked fine. However, I've recently noticed that this function sort of "caps out" at about 32,000 characters (seems to be a bug with the function itself). I remembered your reply about using the window.external.SetChartValue method to manually override the DOCUMENT.TEMPHTML Document Variable and I've been playing around with that the past few days.
Using this function solves the Text Translation character limit. However, when I replace all HTML encodings in the database the Text Translation doesn't update properly to show that I've replaced these values and the encodings are still showing up.
Is there a step you're aware of that I'm missing?
Much appreciated,
Matt