Profound Logic Forums

The web service is up and running but won't work from a rich display screen. web service runs on local host 127.0.0.1:41951. works fine outside of profound but not from within profound. Works with IE without web service because it uses a plugin but we use EDGE.
Has anybody gotten this to work?

Please provide enough information for us to understand and reproduce the problem. As it stands about all I know is that you're running some sort of web service (absolutely no more than that) and that its not working for some purpose (no idea what purpose) but is working for some others.

Is this a continuation of a conversation you had with someone earlier? If so, can you provide a link to that conversation, or provide the details, because I have no idea what you're talking about.

Within the past few weeks I added a web service process to a rich display file. It is to capture a Finger Vein (like fingerprint). I had it easily working in POSTMAN but the hardest time with the "onclick" on the webpage. I finally got it, see below


Sorry - please ignore if this has nothing to do with what you are trying. For everyone else, if you are looking to implement Biometrics with Profoundui this might help.

BanyanAir, Thanks for trying to help!
I'm a RPG programmer so this is all new to me.

I loaded the DYMO software and confirmed it is all working (web service connected, etc), Installed the DYMO printer in windows 10.
In my display file under "external javascript" I have
"http://www.labelwriter.com/software/dls ... ork.3.0.js"
I have an onclick event button to print the label "testLabels("CUSTACCTS1");" (see js file attached)
When I try to debug from the browser it looks like it thinks the web service is not running but it is (not sure).
The javascript has some sort of call back after it goes thru the initialize process (I'm not sure how to implement that with a profoundUI screen).

If I go to this sample page http://www.labelwriter.com/software/dls ... abels.html
it works like it should. I attached the javascript from the above URL that works "printLabelsDymo.txt". (renamed suffix to txt)

website for sample "http://developers.dymo.com/2016/11/29/s ... s-samples/"
PDF FAQ "http://developers.dymo.com/wp-content/u ... WinMac.pdf"

Any and all help is greatly appreciated!
I thought surely someone on the forum has printed labels on a DYMO printer.
Kenny

Have you debugged your code? What is/isn't working? Are there any error messages in the console?

I have tried my best to debug with the browser tool, stepping through DYMO.Label.Framework.3.0.js but it is really complicated. It looks like possibly it thinks the web service is not running but it is. A possible problem is I'm not sure how to implement it on a button click because of the requirement to do an initialize then call back in java script. I have spent many hours trying to debug this.
Kenny

The difference between the one outside of Profound that works and from within my Profound screen after this statement:

function Sd(){var a=Qd();return a?{Port:a.ServicePort,Host:a.ServiceHost}:Nd()?{Port:Pd("ServicePort"),Host:Pd("ServiceHost")}:{Port:window.f,Host:window.c}}


Mine that DOES NOT WORK is not returning "ServiceHost" or "ServicePort", instead returning grid values?

a [object Storage]
__proto__ [object StoragePrototype]
pui-grid-UBALIB-UBA000FM-UBA000S1 {"sort":{"columnId":1,"descending":false},"cols":"51,80,187,187,80,80,80,76,76,76,76,60,33,85,70,0,0,0,0,5"}
pui-is-mouse-capable true


The one that works:
a [object Storage]
__proto__ [object StoragePrototype]
ServiceHost 127.0.0.1
ServicePort 41951

Ah, I think I see what's going on, here.

Its a common practice in JavaScript frameworks to "minify" the code. This shrinks the code by abbreviating variables to shorter names amongst other things meant to make it as small as possible, and combine different source files into a single file to optimize downloads, and stuff like that. For example, if you were to look at the source code that runs behind Profound UI, you'd see that there are about 1500 files and its about 80mb in size. However, when minified, its shrunk down to only about 2mb, and for most situations there's only 1 or 2 files to download. It makes a huge difference in terms of memory usage and performance.

It looks like the Dymo software is minifying their code, and its shortening one of their functions to the name 'Sd'. Note that this minified name is generated on the fly, so it might be different in different versions of the software.

Profound UI is also minified, and I'm guessing that that when we minified it, it also resulted in a function named 'Sd'. Again, it's different each time it is minified, and my copy doesn't happen to have an 'Sd' in it, but I bet yours does. That is exactly the sort of name it tends to use, so it would make perfect sense.

In that case, the Profound 'Sd' routine might be replacing the Dymo one, causing this to malfunction.

Perhaps the solution is to load the Dymo code in an iframe and call it from there? At least, that's what comes to mind.

Thank you Scott,
Could you get me headed in the right direction?
DYMO only supplies the URL http://www.labelwriter.com/software/dls ... ork.3.0.js
for the javascript.

Since I don't have a Dymo printer, there's no way I can test this.

However, I'll do my best to guess at what the code would be. Please see the attached files, labelPrint.js, and labelFrame.html. (The .txt extensions were added to make them easier to work with in the forum, you should remove these extra extensions after downloading.)

What you'll want to do is:

1. Create a folder in the IFS named /www/YOUR-PROFOUND-INSTANCE/htdocs/dymo (i.e. a new "dymo" directory under /www/YOUR-INSTANCE/htdocs)
2. Upload the labelFrame.html file to that directory
3. Upload the labelPrint.js file to that directory
4. Download the DYMO.Label.Framework.3.0.js file from the external web site also to that same directory.
5. Use the "External JavaScript" property to: /dymo/labelPrint.js
6. Set your screen's onload event to: sylacauga.loadLabelFrame();

The idea is that when your display loads, it will run the JavaScript code in the sylacauga.loadLabelFrame() function. Take a look at the code in the labelPrint.js to see what that code does. You should see that it creates an iframe HTML element and positions it on the screen. The element points to the /dymo/labelFrame.html file. This frame is where the dymo code will actually reside so that it doesn't conflict with profound ui.

Take a look at the labelFrame.html file to see what it does. It prints a message to let the user know that it's loading, and loads the DYMO.Label.Framework.3.0.js file. After it has loaded, it calls the "sylacauga.frameLoaded" function in labelPrint.js to notify it that things have finished loading.

Take a look at the sylacauga.frameLoaded function. It receives the dymo object that was loaded in the frame as a parameter to allow you to access it later. It also hides the frame -- the frame is still there, but is not visible to the user anymore, so the message saying it is loading is also no longer visible (so it will appear to be loaded.)

Now that its loaded, your application can call the "sylacauga.printLabels" function to print things. This is also found in labelPrint.js. This is mostly the same as the example you posted earlier, except that I modified it a little bit to make it easier to read, remove extra comments, and to add the code to refer to the dymo object that we received in the earlier step.

I can't test that last bit since I don't have a dymo printer or the web service. Because I can't test it, I also can't be sure that the dymo software will work in this setup. But, this is the best I can do...