Thanks for the quick reply – it’s good to know that it is my data and not me. We’ve posted the hosted service as a proof of concept while we are doing the data development for the version that will become the mapservice. I’m guessing that if I were working with a mapservice, I may not have encountered the issues? The shape query I can get to work, I have struggled with most of the value queries that I have tried to build.
I’m going to set this work aside knowing that it won’t work with the combination of data and widgets that I currently have available. I hope to have a mapservice by the end of the week and will pick with using version 1.2.0.4 then.
If you want the buffer to appear in the print then go to the "Edit default buffer properties" and choose "Add the buffer layer to the maps legend"
Okay thanks. I tried that but found the buffer graphic was still turning off when the eSearch widget is closed but now I see that if I open the layer list and turn off the buffer graphic an then turn it on again, it will stay then on.
After last nights (10/13/2015) Microsoft updates, i seem to have lost all my ESearch attribute queries for some reason. I have WAB 1.2 installed on 2 machines, with the same Main GIS app installed and also a copy on my web server, and they're missing from all of them. The only thing I can think of that happened to all of them are the critical updates.. Have you seen this behavior? I just wanted to check with you before I did anything drastic..
thanks again for your work. i believe the ESearch versions were all 1.2.0.3
I downloaded widget yesterday and seems to be working great except for one part. For some reason the URL parameter search isn't working. I have it checked on in the UI but it won't show up in the "Results" tab. Also when I try a search using URL parameters I get an error asking for a value even though the value is in the URL (link for reference). Is there a common thing I'm missing or did something change with the most recent update?
Thanks for all your work on this, I wish ESRI took as much initiative as you!!
Yes Sir, once again- Bingo !. That was it. Wow. i just visually checked it and it appeared working but i just republished it and now all the other layer queries are working correctly. i wouldve thought just that subdivision query should have been greyed out and the others still work.
I found the issue to be that the url search was not populating the text box and thus was firing the required field warning. I have fixed this in the 1.2.0.5 version and it will be available latter this week.
I love the widget - it has been extremely useful. I just wondered if there was a way to allow users to manually search by a coordinate? I know there is the Enhanced Locate Widget, but our users often need to search and return results by a precise (BNG) coordinate.
The eLocate and eSearch are integrated to work together now in version 1.2.0.4. I do not have any plans to add coordinate search ability into the eSearch. The eSearch is already a extremely complex widget.
First off this widget is amazing. Thank you for all your hard work.
Any clue on why the layer symbology from server would not translate through? I have a layer with specific symbology that isn't being applied when the esearch is performed.
Any clue on why the layer symbology from server would not translate through? I have a layer with specific symbology that isn't being applied when the esearch is performed.
Are you using any advanced cartographic symbology that is not supported by ArcGIS Server?
Are there any plans to be able to do multiple statement expression queries? For example I want people to be able to search by both a permit date range and the hole direction.
I actually just figured it out...go figure right after I post a question. I had the layers filtered by hole direction, as soon as added that as a requirement into my expression the symbology came through. Works beautiful now. My users are going to be thrilled with this!
Your plan sounds perfect to me. You have already added the core essentials I needed the most to migrate our Flex Apps to your JavaScript version of your Enhanced Search Widget.
Having the added functionality of performing Table Searches, and being able to do a search based on Time will be the icing on the cake.
I like all the enhancements you have included in version 1.2.0.4, and I am testing them out against the 6 Themes. Looks wonderful so far!
I like how the Use Existing Enhanced Locate Widget Graphics Tool remains hidden when the user has not yet located a point using the Enhanced Locate Widget.
You have fixed all the related issues with the Degrees Minutes Seconds input.
The coordinates are being read correctly.
I like how the Use Existing Enhanced Locate Widget Graphics Tool appears when the user locates a coordinate.
When you clear the results from Enhanced Locate Widget, this tool gets removed.
I wish there was a way to make the Identify and Enhanced Search Widget work independently with one another, especially while using the Dart Theme which allows you to have multiple widgets open at the same time.
I am using Identify 1.2.0.2 and eSearch 1.2.0.5 in this example:
The only way out is to Clear the Results from the Enhanced Search Widget.
Then, open the Identify Tab, and redo the Select by Extent Tool.
With the Enhanced Search Results cleared, the Identify works as expected.
This means the user has to remember, to clear the Search Results first before attempting to perform an Identify.
However, it is not necessary to clear the Identify Results prior to performing an Enhanced Search.
Click on the Search button.
The Enhanced Search works, even though the Identify Results have not been cleared.
It would be a nice enhancement if the Identify Tool could be made to work without having to clear the results from an eSearch.
However, I do understand this can be a very complicated logic to implement with multiple graphics layers. You have already fixed the bug with duplicate listings that was very annoying.
I like how the Layer List can be moved out of the way by closing the Left Panel.
Robert, this is an extraordinary amount of work you have done for our Web AppBuilder Community. These 8 Custom Widgets boosts the power and functionality of the Web AppBuilder platform to a whole new level.
I am amazed to find how easy it is to create these fully responsive designs in a matter of hours without having to write a single line of code.
Your GUI makes it idiot proof to configure these widgets. I find this far simpler compared to how we had to manually doctor the xml files in the Flex Version.
The latest enhancement of Removing required from all inputs unless the field is marked as required (#3 in your list) was so needed and I'm so happy you've added this flexibility to the widget.
What I found out is that when I ask about two fields or more, it doesn't add the AND between the different fields and therefore the search fails. As soon as I add the and in REST, it works.
I wonder if I use it correctly or it is some kind of a bug.
This is strange what happens when I add a second expression value the "Get features in the layer that match [drop down here] of this and the preceding expression criteria" is set to "All" which equates to "AND" being added to the SQL. You can choose "Any" which means "OR" is added to the SQL. In your screenshots the dropdown is empty... Does the dropdown in your screen shot for the second and third expression value contain any text? It is suppose to default to "All"
I am having a tough time trying to figure out why people are putting 1=1 in the definition query field. What do I need to change in the help and widget UI that will tell every one that the definition expression is identical to what you would use it for in ArcMap to limit the results to a subset of data.
This the way ArcMap help explains it:
When you specify a dataset that you want to draw as a map layer, you often only want to draw some of the features in the dataset. In these situations, you can define a query expression to select a subset of features for the layer display. This is referred to as a definition query.
For example:
You might want to display only cities with a population above a certain threshold.
Many datasets, such as roads and street datasets, have subsets of features (classes), and you might want to define map layers for each class of roads independent of the other features.
In another case, you might have large enterprise databases with datasets that contain millions of features across wide extents—say for a whole nation or state. Yet, in your maps, you might want to work with only a subset of that data.
If you only want to display and work with a subset of features in a layer, you can apply a definition query to a layer.
When you enter 1=1 there it screws with the search results and does not allow for adding and removing like you are reporting.
Thanks I got this one figured out already and fixed. I would only occur if it was the first result in the list you were trying to remove (likely why I missed it in my testing initially).
I am interested in using this widget only for the Graphical search functionality. I had hoped I could simply point it to a map service that has around 50 layers, and it would have an All Layers kind of functionality, similar to Identify. However, I discovered I had to add every layer individually, with a dummy expressions. This is okay, however. I am just using a random field for each layer, with Ask for Values as an expression.
But, if eSearch could have an "All Layers" as the top choice in the Search Layer menu in the Graphical Search tab, that would be great. What do you think?
Basically, this kind of replicates Identify. ...why?.. Because eSearch sends results to the Attribute Table, this is why. If Identify could do that it would not be necessary. However I think I'd asked you about this earlier and I think there was a reason for this. Perhaps because of using identify instead of querytask? Anyhow thank you for your thoughts on this Robert and fellow widget fans.
edit: I am also experiencing issues, some layers are not loading, and also results from one layer are showing up in another. And sometimes polygon symbology is not working, it is not shading in the result only outlinng in red, and I have already tried changing it. Maybe this is all happening because I am using it in such an unusual way. I am using an internal service, but I will be sure to post example sometime today, if I can not get it working, using a public service and map.
i have one that has to do with the attribute table.
i realize you are using what ESRI provides but it would be really handy to be able to export a .csv file that reflects the columns that have been turned off. i also notice that the column names are the actual names and not the aliases that i have assigned. maybe this should go into the "ESRI ideas" site instead of here.
glenn hazelton good idea, and while perhaps Robert could grab the data and prune those columns before passing, ESRI might as well do this at the Attrib. Table widget level anyway. Perhaps ESRI could set a property in the Attrib widget to just allow widgets sending data into the Attrib Table to flag columns to hide.
Something else that just occurred to me: can we make hotlinks in the Attribute Table? You know how we can make them in Robert's Identify? Kind of like in the infowindow popups. I use them to make the Property Tax ID # link to the tax assessor card for each parcel. Would be nice to have that in the Attrib. Table. I am sure it could be hacked via html/css or someuch but it would be neat if ESRI designed the attribute Table to be very customizable like infowindow popup. I didn't see anything about it in the documention but if there is some description on it either Esri or unofficial I'll take a look and give it a try.
Having an all layers option on the Graphical search is not practical. What it comes down to is understanding the mechanisms used behind the scenes. The Identify widget make this possible because the IdentifyTask uses the map to identify features from the whole map (if so configured). The eSearch (and Query widget) use a QueryTask which is one layer of a map service at a time. So in your scenario I would have to send 50 round trip queryTasks to the server to see if the graphic intersect the feature layer.
The identify widget would have to be majorly re-coded to produce a featureLayer in order for it to send results to the Attribute table (just not in any of my plans for this widget currently).
I am also experiencing issues, some layers are not loading, and also results from one layer are showing up in another. And sometimes polygon symbology is not working, it is not shading in the result only outlinng in red, and I have already tried changing it
Not sure where to begin here... I have not had anyone report of having these issues.
Yes of course, I am just getting in to it and I'll report back on specific issues with more detail and example site, if needed.
As to IdentifyTask vs QueryTask I understand, and this is what I'd thought, but I just wanted to doublecheck. And yes...that makes sense, that would be an extreme amount of network traffic, that many requests. Hm. Well it is ok, users can just go layer by layer. Which to be honest, it would be rather ungainly to see dozens of results layers pop up at once. Almost unusable. So good point, that isn't really a sensible use case. I will keep working today on employing your widget, for my rather unorthodox purposes. Thanks for being here and discussing!
Oh, also: The multipart graphic search is GREAT. I think it will be very appreciated by our people.
edit: Also, I figured out my symbology issue. It was configured to get it from Server. Now that I see how that works, that's really awesome! I am going to override it in this case, but that's slick.
';
}
}
}
catch(e){
}
}
}
if (newSub.getAttribute("slang").toLowerCase() != code_l.toLowerCase()) {
if (trLabelsHtml != "") {
var labelSname = "";
if(labelEle[i].querySelector("ul li:nth-child(1)").getAttribute("aria-hidden")){
labelSname = labelEle[i].querySelector("ul li:nth-child(1)").outerHTML;
}
labelEle[i].innerHTML = "";
labelEle[i].innerHTML = labelSname + trLabelsHtml;
}
}
}
}
}
catch(e){
}
}
}
/* V 2.0:3 = Store not translated reply id */
if(lingoRSXML.snapshotLength == 0){
if($scope.falseReplyID == "") {
$scope.falseReplyID = value;
}
}
/* Get translated Body of Replies/Comments */
var lingoRBXML = doc.evaluate(lingoRBExp, doc, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for(var i=0;i 0) {
var attachDiv = rootElement.querySelector('div.lia-quilt-row-main').querySelector('div.custom-attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
}
else if(rootElement.querySelector('div.lia-quilt-row-main').querySelectorAll('#attachments').length > 0){
if ("TkbArticlePage" == "BlogArticlePage") {
attachDiv = rootElement.querySelector('div.lia-quilt-row-main .lia-message-body-content').querySelector('#attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
}
else{
attachDiv = "";
}
}else{
attachDiv = rootElement.querySelector('div.lia-quilt-row-main').querySelector('#attachments').outerHTML;
}
}
else {
attachDiv = "";
}
/* Feedback Div */
var feedbackDiv = "";
var feedbackDivs = rootElement.querySelector('div.lia-quilt-row-main').querySelectorAll('div.lia-panel-feedback-banner-safe');
if (feedbackDivs.length > 0) {
for (var k = 0; k < feedbackDivs.length; k++) {
feedbackDiv = feedbackDiv + feedbackDivs[k].outerHTML;
}
}
}
else {
var attachDiv = rootElement.querySelector('div.lia-message-body-content').querySelector('div.Attachments.preview-attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
} else {
attachDiv = "";
}
/* Everyone tags links */
if (document.querySelectorAll("div.TagList").length > 0){
var everyoneTagslink = document.querySelector('div.lia-quilt-row-main').querySelector(".MessageTagsTaplet .TagList");
if ((everyoneTagslink != null)||(everyoneTagslink != undefined)){
everyoneTagslink = everyoneTagslink.outerHTML;
}
else{
everyoneTagslink = "";
}
}
/* Feedback Div */
var feedbackDiv = "";
var feedbackDivs = rootElement.querySelector('div.lia-message-body-content').querySelectorAll('div.lia-panel-feedback-banner-safe');
if (feedbackDivs.length > 0) {
for (var m = 0; m < feedbackDivs.length; m++) {
feedbackDiv = feedbackDiv + feedbackDivs[m].outerHTML;
}
}
}
}
} catch (e) {
}
if (body_L == "") {
/* V 2.0:7 Replacing translated video data with source video data */
var newBodyVideoData = newBody.querySelectorAll('div[class*="video-embed"]');
angular.forEach($scope.videoData[value], function (sourceVideoElement, index) {
if (index <= (newBodyVideoData.length - 1)) {
newBodyVideoData[index].outerHTML = sourceVideoElement.outerHTML
}
});
/* V 2.0:7 = Replacing translated image data with source data */
var newBodyImageData = newBody.querySelectorAll('[class*="lia-image"]');
angular.forEach($scope.imageData[value], function (sourceImgElement, index) {
if (index <= (newBodyImageData.length - 1)) {
newBodyImageData[index].outerHTML = sourceImgElement.outerHTML;
}
});
/* V 2.0:7 = Replacing translated pre tag data with source data */
var newBodyPreTagData = newBody.querySelectorAll('pre');
angular.forEach($scope.preTagData[value], function (sourcePreTagElement, index) {
if (index <= (newBodyPreTagData.length - 1)) {
newBodyPreTagData[index].outerHTML = sourcePreTagElement.outerHTML;
}
});
}
var copyBodySubject = false;
if (body_L == "") {
copyBodySubject = true;
body_L = newBody.innerHTML;
}
/* This code is written as part of video fix by iTalent */
/* try{
var iframeHTMLText = body_L;
var searchIframeText = "<IFRAME";
var foundiFrameTag;
if (iframeHTMLText.indexOf(searchIframeText) > -1) {
foundiFrameTag = decodeHTMLEntities(iframeHTMLText);
foundiFrameTag = foundiFrameTag.split('src="')[1];
body_L = foundiFrameTag;
}
}
catch(e){
} */
/* This code is placed to remove the extra meta tag adding in the UI*/
try{
body_L = body_L.replace('<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />','');
}
catch(e){
}
/** We should not replace the source content if user profile language and selected target language matches with source language **/
if(showTrContent) {
var compiled = false;
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = null
if("TkbArticlePage"=="IdeaPage"){
// var customAttachDiv = '';
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv ;
$compile(rootElement.querySelectorAll('div.lia-message-body-content')[0])($scope);
compiled = true;
/* Attach atttach div */
// document.querySelector("div.translation-attachments-"+value).innerHTML = attachDiv;
rootElement.querySelectorAll('div.lia-message-body-content')[0].insertAdjacentHTML('afterend',attachDiv);
if(rootElement.querySelectorAll('div.lia-quilt-idea-message .lia-message-body .lia-attachments-message').length > 1){
rootElement.querySelectorAll('div.lia-quilt-idea-message .lia-message-body .lia-attachments-message')[1].remove();
}
} else {
if("TkbArticlePage"=="TkbArticlePage"){
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv ;
}else{
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv + attachDiv;
compiled = true;
}
}
/* Destroy and recreate OOyala player videos to restore the videos in target languages which is written by iTalent as part of iTrack LILICON-79 */ /* Destroy and recreate OOyala player videos */
try{
// $scope.videoData[value][0].querySelector("div").getAttribute("id");
for(var vidIndex=0; vidIndex<$scope.videoData[value].length; vidIndex++){
if( $scope.videoData[value][vidIndex].querySelector("div") != null){
var containerId = LITHIUM.OOYALA.players[$scope.videoData[value][vidIndex].querySelector("div").getAttribute("id")].containerId;
videoId = LITHIUM.OOYALA.players[$scope.videoData[value][vidIndex].querySelector("div").getAttribute("id")].videoId;
/** Get the Video object */
vid = OO.Player.create(containerId,videoId);
/** Destroy the video **/
vid.destroy();
/** recreate in the same position */
var vid = OO.Player.create(containerId,videoId);
}
}
}
catch(e){
}
try{
for(var vidIndex=0; vidIndex<($scope.videoData[value].length); vidIndex++){
if($scope.videoData[value][vidIndex].querySelector('video-js') != null){
var data_id = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-video-id');
var data_account = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-account');
var data_palyer = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-player');
var div = document.createElement('div');
div.id = "brightcove";
div.class = "brightcove-player";
div.innerHTML =
'(view in my videos)'
var data = div.getElementsByClassName("video-js");
var script = document.createElement('script');
script.src = "https://players.brightcove.net/" + data_account + "/" + data_palyer + "_default/index.min.js";
for(var i=0;i< data.length;i++){
videodata.push(data[i]);
}
}
}
for(var i=0;i< videodata.length;i++){
document.getElementsByClassName('lia-vid-container')[i].innerHTML = videodata[i].outerHTML;
document.body.appendChild(script);
}
}
catch(e){
}
if(!compiled){
/* Re compile html */
$compile(rootElement.querySelectorAll('div.lia-message-body-content')[0])($scope);
}
}
if (code_l.toLowerCase() != newBody.getAttribute("slang").toLowerCase()) {
/* Adding Translation flag */
var tr_obj = $filter('filter')($scope.sourceLangList, function (obj_l) {
return obj_l.code.toLowerCase() === newBody.getAttribute("slang").toLowerCase()
});
if (tr_obj.length > 0) {
tr_text = "Esri may utilize third parties to translate your data and/or imagery to facilitate communication across different languages.".replace(/lilicon-trans-text/g, tr_obj[0].title);
try {
if ($scope.wootMessages[$rootScope.profLang] != undefined) {
tr_text = $scope.wootMessages[$rootScope.profLang].replace(/lilicon-trans-text/g, tr_obj[0].title);
}
} catch (e) {
}
} else {
//tr_text = "This message was translated for your convenience!";
tr_text = "Esri may utilize third parties to translate your data and/or imagery to facilitate communication across different languages.";
}
try {
if (!document.getElementById("tr-msz-" + value)) {
var tr_para = document.createElement("P");
tr_para.setAttribute("id", "tr-msz-" + value);
tr_para.setAttribute("class", "tr-msz");
tr_para.style.textAlign = 'justify';
var tr_fTag = document.createElement("IMG");
tr_fTag.setAttribute("class", "tFlag");
tr_fTag.setAttribute("src", "/html/assets/langTrFlag.PNG");
tr_fTag.style.marginRight = "5px";
tr_fTag.style.height = "14px";
tr_para.appendChild(tr_fTag);
var tr_textNode = document.createTextNode(tr_text);
tr_para.appendChild(tr_textNode);
/* Woot message only for multi source */
if(rootElement.querySelector(".lia-quilt-forum-message")){
rootElement.querySelector(".lia-quilt-forum-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-message-view-blog-topic-message")) {
rootElement.querySelector(".lia-message-view-blog-topic-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-blog-reply-message")){
rootElement.querySelector(".lia-quilt-blog-reply-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-tkb-message")){
rootElement.querySelector(".lia-quilt-tkb-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-tkb-reply-message")){
rootElement.querySelector(".lia-quilt-tkb-reply-message").insertBefore(tr_para,rootElement.querySelector(".lia-quilt-row.lia-quilt-row-footer"));
} else if(rootElement.querySelector(".lia-quilt-idea-message")){
rootElement.querySelector(".lia-quilt-idea-message").appendChild(tr_para);
} else if(rootElement.querySelector('.lia-quilt-occasion-message')){
rootElement.querySelector('.lia-quilt-occasion-message').appendChild(tr_para);
}
else {
if (rootElement.querySelectorAll('div.lia-quilt-row-footer').length > 0) {
rootElement.querySelectorAll('div.lia-quilt-row-footer')[0].appendChild(tr_para);
} else {
rootElement.querySelectorAll('div.lia-quilt-column-message-footer')[0].appendChild(tr_para);
}
}
}
} catch (e) {
}
}
} else {
/* Do not display button for same language */
// syncList.remove(value);
var index = $scope.syncList.indexOf(value);
if (index > -1) {
$scope.syncList.splice(index, 1);
}
}
}
}
});
});
/* V 1.1:2 = Reply Sync button for multi source translation */
} catch(e){
console.log(e);
}
};
if((rContent != undefined) && (rContent != "")) {
drawCanvas(decodeURIComponent(rContent));
/** Update variable with selected language code **/
$scope.previousSelCode = code_l;
}
};
/**
* @function manageTranslation
* @description Managess the translation of given language for the thread
* @param {string} langCode - Language Code
* @param {string} tid - Thread ID
*/
$scope.manageTranslation = function (langCode, tid) {
//debugger;
$scope.showTrText = false;
/* V 2.0:5 = actualStatus variable introduced to indicate detailed connector status on UI. This variable holds the actual translation percentage */
$scope.transPercent = "";
$scope.actualStatus = "";
if (tid != "") {
var bulkTranslation = lithiumPlugin.bulkTranslation(langCode, tid);
bulkTranslation.then(function (trContent) {
if(trContent.body != "") {
$scope.showPreview(trContent.body, $scope.mszList, langCode);
if(langCode != "en-US") {
$scope.showTrText = true;
}
}
if((trContent.status != "NA") && trContent.status != null) {
// $scope.transPercent = String(trContent.status);
$scope.actualStatus = String(trContent.status);
} else {
// $rootScope.errorMsg = "Translation is in progress. Please check again a few minutes."
$rootScope.errorMsg = "Translation is in progress. Please retry in a few minutes."
}
$scope.workbench = trContent.wb;
/* V 2.0:4 = Trigger uncalled or delayed callbacks (documnet uploaded/translation completed from lithium).*/
if(trContent.callback == 'true') {
var trCompletCallback = lithiumPlugin.trCompletCallback(langCode, trContent.docID);
trCompletCallback.then(function (callback){
// $rootScope.errorMsg = "Downloading Translated content in " + langCode + " now. Please check again in a few minutes."
$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
});
} else if (trContent.callback == 'upload') {
var trCompletUpload = lithiumPlugin.trCompletUpload(langCode, trContent.docID);
trCompletUpload.then(function (callback) {
//$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
});
} else if ("many" == "one") {
$scope.updateOOS();
} else if("SmartConx" == "SmartConx"){
if ("many" == "many"){
$scope.updateOOS();
}
}else if ((trContent.status != null) && trContent.status.includes("100")) {
/* If everything fine then only check Out of Sync status */
$scope.updateOOS();
} else {
/* If translation perccent is less than 100 then show the percentage on UI */
$scope.transPercent = $scope.actualStatus;
}
});
}
}
/**
* @function selectThisLang
* @description Called on select dropdown.
* @param {string} lang - Language code
*
*/
$scope.selectThisLang = function (lang, anonymousFlag) {
/* 1.4:3 Update Analytics on language selection */
try {
setTimeout(()=>{
lingoThreadLangSelected(lang, '910880');
console.log("Language",lang);
},5000)
} catch (e) {
console.log(e);
}
/** Display Translated content **/
var getTranslation = lithiumPlugin.getTranslation(lang, "910880");
getTranslation.then(function (trContent) {
if (trContent.body != "") {
$scope.showPreview(trContent.body, $scope.mszList, lang);
} else {
//$rootScope.errorMsg = "Translation is in progress. Please check again in a few minutes."
$rootScope.errorMsg = "Translation is in progress. Please retry in a few minutes."
}
});
};
var decodeEntities = (function() {
// this prevents any overhead from creating the object each time
var element = document.createElement('div');
function decodeHTMLEntities (str) {
if(str && typeof str === 'string') {
// strip script/html tags
str = str.replace(/