Latest Contributions by Andy_Morgan

Thanks @DougBrowning for staying with me and offering more explanation and links. After some experimenting I see it's possible to get attributes transferred over. I never would have thought you can do a loop within Field Maps to call it with a URL from the popup. I don't like how you have to click the target GPS layer again when it reloads, but I saw in a separate thread ESRI did it by design for layer templates. I suppose this type of solution is better for what I need and more customizable all around. Certainly not an obvious workaround, and unfortunately a lot of effort that could have been avoided if attributes could simply be copied across various geometry types.   ... View more

I really do want to follow you, but again I'm not clear. It's not that I don't understand how to write code, it's that I don't understand how to implement what I think you're suggesting: to generate a custom URL in a field value that'll display within the polygon popup...and the click event for this URL will somehow trigger a function to send all the selected polygon attribute values to the new GPS feature ($feature) through Arcade. That's a giant stretch from what I thought was even possible in an AGO web map + Arcade. Is this something people are already doing with examples, or something you suspect is possible but haven't actually done yourself? Just wanted to be clear. It may seem quick and easy , but that's because you already know how to do it. There are at least two steps in this workflow for which I'm not able to find ESRI documentation, so it's not obvious to me yet. ... View more

Absolutely no pressure to keep going with this conversation, but just to clarify the desired starting point for copying attributes is the user clicks on a parcel boundary (polygon) to indicate which feature they want to use for transferring the many field values we need in the new GPS point. Polygon attributes -> GPS point using "Copy attributes" isn't possible out of the box in Field Maps. I'm not following when you say "you'd have the popup of the point...". The goal is to not be clicking on a parcel centroid point like I have it now. I'd like them to click on parcel boundary polygons and exclude the centroid points layer entirely. They will clutter the map, since I have a separate meter point layer that will be used as well. Our field staff likely prefers to click on polygons instead of finding the appropriate point in the center. The problem is that the point to be collected by GPS isn't always inside the polygon. Regardless of whether there is anything else to add, any input is much appreciated!  ... View more

Thanks @DougBrowning and @ZakBaron for offering ideas. Perhaps I missed something, but neither of those seems to offer a workaround for my exact need of selecting a polygon, using the selected polygon to then select the centroid point, and then copy attributes from the centroid point to the GPS feature being collected. URL parameters and relates are more for adding related features. Arcade solutions are for intersecting/containing polygons for wherever you're collecting a GPS feature, not what you clicked to manually select as the intended reference polygon to use for GPS point attributes. I cannot be guaranteed the GPS point will always be inside a polygon. It might be a few feet outside, and then the rule wouldn't apply. The user would have no direct control over which feature was used for copying attributes. I'll keep exploring. I just wish "Copy attributes" would apply across any two geometry types (point to polygon, polygon to line, polygon to point, etc.). I realize you can press down on a field to manually copy a single attribute and the manually paste it into a field in the new point, but I'm designing a solution for 50-100 thousand points over 2 years. I need the field workers to not have to do something tedious like all these steps every time. Using the "Copy attributes" button is by far the fastest and most foolproof method.     ... View more

Hi Noah, True, I don't think the solution is perfect for the reasons you've stated, but here's my final solution below. I had to add a second function on top of the initial wrapped text in order to break really long continuous strings that exceeded the preferred character max.  For example, if you included a long hyperlink like "https://community.esri.com/t5/arcgis-api-for-javascript-questions/print-task-not-printing-textsymbol-in-correct/m-p/1102254" function addLineBreaks(textLabel) { //apply line breaks to wrap text with max width of 50 characters const wrappedText = textLabel.replace( /(?![^\n]{1,50}$)([^\n]{1,50})\s/g, '$1\n' ); return wrappedText.replace(/(.{80})/g, "$1\n"); }   My text symbol is defined as follows: var textSymbolGeneric = { type: "text", // autocasts as new TextSymbol() color: "white", haloColor: selectedColor, haloSize: "1px", text: "", xoffset: 0, yoffset: 0, font: { size: 12, family: "sans-serif", weight: "bold" }, lineWidth: 300, horizontalAlignment: "left", verticalAlignment: "bottom" };   This is how it looks for verticalAlignment: "bottom" Note the orange circle edit point which indicates the starting point for where I clicked to add the text.   This is how it looks if I accept the default verticalAlignment value of "baseline"   While the baseline setting is preferred, since it goes downward based on where you clicked and started your text, the problem is when our users go to export the map to pdf. They expect whatever is showing on the map, with all their redline markups and text, will be sent to another person and appear the same way. I am forced to make text start from the "bottom" only because it's reliable in the output pdf. The result of printing the last image above, with "baseline" as the vertical alignment, will be the following. I realize it's difficult to compare to the one above without the line and point features, but you can see the text shifted to way above the thick white (highway) line.    Side note: all the layers you're seeing turned on in this output pdf are not visible (unchecked in the layer list). This is a JS 4.20 application, way too large to share all the code broken up into many files. This is either another bug or something going on with my code. Either way it's not obvious to me yet, because the Web Map JSON string does not include those layers you see shown (blue and red lines, the yellow points, etc.). I would think the print task is including too much, but again maybe an oversight by me somewhere.  For the sake of staying on topic with the original post I will not go further with this issue. I'm unfortunately out of time to offer anything else for now. It may be days before I can return to this discussion.        ... View more

Also, I noticed multi-line text needs a vertical alignment of "bottom" in order to have a predictable location in the output pdf. verticalAlignment: "bottom" Otherwise, the default "baseline" setting will throw all text upward (when rendering the pdf) rather than going downward as it increases in length. ... View more

Noah, thank you so much for looking into it. Will this bug be marked by the ESRI Development team as a fairly high priority? Soon I will be deploying an application I've migrated from 3.x to 4.x, and I discovered lineWidth is ignored at the last minute.  Taking your idea of adding line escapes, some of us need to do this dynamically. So I found a handy regular expression that works to wrap user input which is being entered through a textarea element. It looks like this patch will do the trick for now.  function addLineBreaks(textLabel) { //apply line breaks to wrap text with max width of 32 characters const wrappedText = textLabel.replace( /(?![^\n]{1,32}$)([^\n]{1,32})\s/g, '$1\n' ); return wrappedText; }     ... View more

I'm having the same problem. The feature layer is only labeling with the code (abbreviation), not the full description, from the domain. I tried useCodedValues = true with version 4.20 and much older versions of the 4.x API. Nothing works, although it does work with MapImageLayer sublayers. const labelClassWaterLine = { labelPlacement: "above-center", labelExpressionInfo: { expression: "$feature.PIPEMATERIAL + TextFormatting.NewLine + $feature.EXPOSURETYPE" }, useCodedValues: true, symbol: { type: "text", color: "red", haloSize: 2, haloColor: "white" } };   ... View more

Yes, this is the answer/explanation. Thanks for posting. I also discovered this and should have mentioned it in an update after my original reply. The API is not so much to blame. It's the API documentation pages where you start to accumulate many cookie issues. ESRI should hopefully make adjustments on their side with the documentation, but for now we'll have to use a different browser to avoid getting a high issue count. On a related note, we also discovered something with our internal facing web server used for hosting the secure JS API web application. If we use the fully qualified name in the application URL it will not have any cookie issues generated from this server. (i.e. "servername.abc.xyz/myapplication" instead of just "servername/myapplication") ... View more

Does anyone have a workaround? This has become a very frustrating problem for me, too. I'm having to wait for 6,000 - 8,000 issues to be logged before my internally hosted application finishes loading. It's a fairly simple 4.19 API application. I really wish we could get ESRI's input on this. ... View more

You're welcome. That's correct, it's applying your function once for each layer's creation. I'm not sure it'll be a noticeable improvement in performance, but it's a must for logic if you only want something done once...or if you're simply trying to debug and you don't want to unnecessarily hit a breakpoint for the same layer multiple times. That's what was annoying me. I just think it's the proper way to handle it, unless they change the API.  ... View more

Hi @NilsBabel1, since we cannot prevent the "listItemCreatedFunction" handler from being called over and over, my only thought was to have it exit if it's already been called for the current layer. So my example points to a function (ex: "layerListActions") when defining the "new LayerList": listItemCreatedFunction: layerListActions   This function is called whenever a list item is created, whether it's the 1st...18th...or 999th time for that same layer. If it's the first time, the layer's (unique) title is added to this array to essentially check it off the list. If we find the layer's title is already added to the array [ arrListItemCreated.indexOf(event.item.title) > -1 ]  then we exit the handler completely. Basically don't do anything and move on, since it's already had some code applied. Here's my full function, if it means anything more. I'm just checking for a certain layer to know if it's turned on (visible). If so, I'm programatically turning on a hidden feature layer. Not a typical case for most people, but it was necessary because I'm pulling in data on the fly from another source. Anyway, hope this explains the use of the array and my logic.    function layerListActions(event) { if (arrListItemCreated.indexOf(event.item.title) > -1) { return false; } else { arrListItemCreated.push(event.item.title); } if (event.item && event.item.layer) { const item = event.item; const layer = item.layer; item.open = item.visible; let lyrVEPByExerciseDate = app.Functions.getLayerFromTitle(app.mapImgLyrUtilMap, "VEP by Exercised Date"); if (!uniqueParentItems.indexOf(item.title) > -1) { uniqueParentItems.push(item.title); item.watch("visible", function (event) { if (app.dynamicFeatLyrVEP && (item.title === "VEP by Exercised Date" || item.title === "Valve Exercise Program")) { if (event == true) { if (lyrVEPByExerciseDate.visible == true) { app.dynamicFeatLyrVEP.visible = true; } } else { app.dynamicFeatLyrVEP.visible = false; } } }); } } }     ... View more

Hey, thanks! The word "bloat" is exactly what I had in mind. I'll take a look at the video. I'm sure this topic could be relevant for countless other beginner to intermediate level JS developers. ... View more