Your widget is amazing! I'm a newbie so forgive me in advance. I've downloaded, installed and configured without issue. But I'm getting an error with one layer, in particular in Specifying parameters for this search dropdown list it only see’s the first item and returns search failed on the remaining items in the list. I have narrowed it down to that it has a domain. If I remove it from the domain, it works. I am using Version 1.1.7 and have exhausted my resources and any help would be appreciated.
OK now all I should need to see is your config_Enhanced Search.json file. This is located in your C:\[install dir]\server\apps\[app num]\configs\eSearch folder
OK, it is not the issue I though it was going to be. Please start a new discussion new Discussion thread that way you can attach the layer data. Give me any details you can about the field domain and values so that I can try and duplicate your environment. Like that type of Geodatabase are you using (file geodatbase, SDE SQL server, oracle, etc).
I think I found the bug that was causing the AttributeTable tool to generate the following errors:
Chrome -- TypeError: Cannot read property 'addChild' of null
Firefox -- TypeError: this.tabContainer is null (this.tabContainer.addChild(cp))
The eSearch._openResultInAttributeTable() method was calling the AttributeTable._openTable method before the data was published and then the AttributeTable.onReceiveData method was calling _openTable again after the data was received.
I submit my solution for your review. In Widget.js of the eSearch 1.1.8 tool I commented out lines 1549-1554 to remove the following lines from the _openResultInAttributeTable method
if(this.wManager) {
var attWidget = this.wManager.getWidgetsByName('AttributeTable');
Thanks but I find that if the table is not open before the publish data then once you clear the results the attribute table will not open with any results for the second search and it give this error:
I am using version 1.1.8 and am getting mixed results when performing a search and having the Search Results populate in the Attribute Table.
Sometimes the Attribute Table widget will get populated with results and other times the Attribute Table will just be blank. I've tested this on IE, FF, and Chrome as well as had other staff test on their machines with the same app. We are all experiencing the same mixed results.
I can get the Search Results to successfully populate the Attribute Table each time IF I first open the Attribute Table widget THEN execute the search.
The app is secured but, if possible, I could send you a link and credentials.
If you look at the web console the error is occurring in the Attribute Table widget and that is outside of my control. The work around that I have found is that when the Attribute Table widget opens but is empty you just need to right click on the layer in the LayerList widget and choose open in attribute table and then it will be fine for each search from that point on. At some point I will discuss this issue with the WAB Dev team and see if we can get some resolution to this.
Is there a way to change the name of the Search Results layer in the print output legend? For example, in the attached image, the legend item in the print output is "graphicsLayer3". Users might find it more helpful if the layer were named something like "Search Results - Layer Name". Should this question be posted outside of the eSearch widget thread?
This is one of those strange things that the JS API does. I add all the searches to the map in the same fashion but some layers print like yours with graphicsLayerXX and some print just fine like this one
I guess I will have to get with tech support and see if I can get this one figured out.
In the attribute search, is there a way to "Limit results to maps extent" by default? It doesn't matter if it is accomplished with a checkbox or not. I am trying to streamline the interface for end-users and would like the widget to always limit the results to map extent.
Working with other widgets I have been able to change the default check box settings from 'false' to true', but in your eSearch app it is not as obvious to find.
Thank you for all of the great work on these widgets,
Thanks Rebecca, that information got me thinking in a different direction and I figured it out. It wasn't a matter of changing 'false' to 'true' because the 'limitMapExtentCbx' was not called out. I added a new line to control that checkbox on start up, and it seems to be working.
The new line was added in widget.js line 355: this.limitMapExtentCbx.setValue(true);
Glad to hear you got it working John. Sometimes all you need is a push past your current thinking. At least that seems to help me (that is, soon as I write it down and press send.....)
I think I have the same issue as you, chrome was throwing 'addChild' of null errors and the attribute table would never get populated. Commenting out the lines you mentioned initially works, the first search the esearch and attribute table are really fast. The get and content download are way under a second. After the initial search it slows to about 12 seconds for the get and download esearch content, and 25 seconds to get and download content for the attribute table. That may be due to the record count of our service, using the find command at the rest endpoint of the service it takes 12 seconds to return a find. Oddly it looks like the attribute table content is downloaded twice. Did you experience similar behavior, and were you able to refine a solution?
The searches are consistent now for me by commenting out those lines. I do not get the same lag you are getting nor do I get multiple attribute table calls. The data to the attribute table should be sent once and can be checked by setting a breakpoint in the Attribute Table code. For 1000 records, the attribute table populates fairly quickly after the eSearch content. How many records are you pulling for display? Are you using version 1.1 of the WAB? Are you watching network traffic with Chrome tools or Fiddler? I will be modifying my service to have more records so may have different results with a larger dataset. Now as a side note, I was having problems with proxy.js that was causing my searches to hang and cause timeout issues (Problems hitting REST services when running App on Node.js server ). I have not yet tested the suggestions for modifying the proxy timeout so cannot report anything else.
I've implemented eSearch to search on our parcel layer which has quite a large number of attribute fields. I've easily configured a link to our assessor parcel maps, but the link shows at the bottom of a very long list of attributes.
Is there an easy way to have that link show up at the top of the attribute list and not at the bottom of Results?
Hi Paul, yes. You can adjust the order of each attribute with the Up and Down buttons. Plus, you can decide for each attribute whether you want it in the list on the right or not. Check off Popup Only to take it out. He just added that recently and it was a lifesaver for me because I had a ton of attribs for each record, probably like yourself, and it made the list on the right not useful. I went through and removed everything but a pink and a name and address for our properties and now it's perfect! Give it a shot, let us know if that works!
Thanks for the reply Kevin. What I'm really hoping to do is avoid having our users scrolling thru a long list of attributes to get to the linked parcel map. I can see in the eSearch setup dialogs that the attribute list can be re-ordered, but the widget seems to handle the Search Links as a separate code block in the config json file. My parcel map link is not part of the attribute list.
In the image, you can see that I've scrolled all the way to the bottom of the attribute list, and the Parcel Map link at the bottom.
So what Kevin is suggesting is that you not have all though attributes present in the widgets search results (by choosing popup only). You can just choose a couple of main attributes to display in the search results and then the link. I do this for my main site just listing owner name, Parcel ID, Parcel Number, and address. The rest of the attributes will still be available just in the attribute table or the popup instead.
Currently there is no configuration to allow the link to appear at the top of the results.
I’m usually pulling one record at a time and combing thru chrome tools to find errors. The lagging behavior is same when it is pulling hundreds of records however. After trial and error I realize the search/zoom/open attribute table is very fast when it is not returning “Uncaught TypeError: Cannot read property 'geometry' of undefined”. I don’t have a good feel as to why this error occurs. Using the default attribute search “(Parcel Number (APN)” on http://betamaps.mcassessor.maricopa.gov/ and search a string such as 20140001 should reveal this behavior. Sometimes I get the error, other times I don’t.
Is there a discussion thread on GeoNet with links to download all your custom widgets that you developed for the last and final version of the FlexViewer 3.7 based on the ArcGIS API 3.7 for Flex?
I know of the following 21 Custom Widgets that you released for FlexViewer 3.7.
This is an extraordinary amount of time and effort you have put in over the last decade to make the Flex platform the Gold Standard of Web Mapping!
Over the next few years as users migrate to the JavaScript API, we hope to see more of your Flex Widgets translated to the Web AppBuilder.
You deserve a Lifetime Achievement Award in GIS for the sheer amount of code you have shared along with all the helpful tips and 24/7 support to our GIS Community.
Thanks for the kind words. Your list was only missing one (for 3.7). I have 4 others that were retired before version 3.7 for different reasons. My plan is to migrate most (some just don't make sense to migrate as the functionality exists in WAB already).
Thanks for the great tool! I am having a printing problem with the enhanced search widget. The search functionality works fine and I currently have it set to "Add Result as Operational Layer." I am searching against a point layer. Everything looks great until I use the out of the box print tool. When I do a print, the point symbols come out huge. Changing the symbol or its size has no effect. I have also tried changing all of the Advanced settings, map scale, extent, etc. with no luck.
I am using Widget Version 1.1.6 and Web AppBuilder 1.1.
I’ve only been working with Web AppBuilder for two months. I’ve been programming since 1991 (Arc/Info aml, ArcView Avenue, VBA and C#) but Web AppBuilder and Javascript is a whole new world so I have a BIG learning curve ahead of me.
The only reason I am using the older version is because that is what I started with and didn’t realize there was a newer version. I will update the widget, try again and let you know what happens.
I was using the same symbol as Tapas, marker 77 yellow but from my tests, the symbol does not matter, I tried four different symbols and had the same issue. As far as I can tell, the issue is limited to just points, Lines and polygons display correctly on the printout.
Do you know if Tapas’ output matches what he sees on the screen? The symbols look pretty big to me on his pdf, granted not as big as they are on mine. Maybe Tapas was zoomed out more than I was. I was zoomed in pretty close.
Please start a new thread on this issue so that you can attach things (comments on the document do not allow for attachments or the use of the advanced editor).