Enhanced Search Widget Version 2.17 - 7/9/21

333861
2653
07-14-2014 03:57 PM
Labels (1)

Enhanced Search Widget Version 2.17 - 7/9/21

Live Preview Site

Web AppBuilder for ArcGIS | Help - Enhanced Search widget

 

List of the latest enhancements and changes:

  1. Fixed Issue with Print Legend using "override 1" for search and/or buffer Layers.
  2. Fixed autozoom issue under certain configurations.

 

Older enhancements or changes

Check the "Older enhancements or changes.txt" in the download for a complete list.

 

Older Versions

Last 2.13 version

Last 2.12 version

Last 2.11 version

Last 2.9 version

Last 2.7 version

Last 2.6 version

Last 2.5 version

Labels (1)
Attachments
Comments

Hey Robert,

Curious if you've had any issues with the popups that are configured in the initial web map conflicting with the "select by shape" option? Basically, when I try to create a polygon or a point to select by, my clicks bring up my pop ups. I can still create my polygon, I just have to ignore the popups and click around them.

Thanks

Tyler

Tyler,

   I have not run into this, but you have great timing as I am working on the next release right now and this will be pretty easy to fix.

Awesome. Thanks a bunch for pointing me in the right direction to all the custom widgets. Knew about it on the Flex forum, but not here. Keep up the awesome work!

Robert,

Since you are working on the next release and since this widget is very popular around the office I would like to submit two possible enhancements we commonly discuss:

1) When searching by attribute eSearch zooms and centers in the screen.  If the attribute table is configured to pop open my screen will not re-zoom and re-center causing some of the selected geometry to reside under the attribute table.  Would it be possible to rezoom and center after the attribute table is open?

2) Some user do not like the attribute table taking real estate after a search.  Would it be possible to add an operational layer, populate the attribute table but not have the attribute table open.  This would allow users control as to when they can show/hide the attribute table.

I have not graduated from the school of wizardry yet so I am not sure how probable these suggestion are but I submit them for your consideration.  Thank you for all of the time and effort you have put into this widget, it has been a valuable asset.

Tim,

   Both great suggestions I will look into. Thanks.

Tim,

  So it turns out that your #1 is a no go. The issue is the Attribute Table Widget automatically opens itself when data is sent to it. The work around fro your users that what to not have the AT to open automatically after each search is for then to configure the layer to NOT have " Show in Attribute Table Widget" checked and then when they do want to see the results in the AT they will have to open the LayerList widget and click on the dropdown arrow next to the Search Results: xx and choose "Open Attribute Table". Your #2 will be in Version 1.1.9.

Tyler,

   You can expect to see this enhancement in Version 1.1.9.

Tapas,

   This will be fixed in Version 1.1.9 for the eSearch and I will add this to my list for the Identify widget as well.

Tim,

Funny…we were just looking at our sites today and thinking the same thing about the AT.  One workaround that I found was that you can resize the AT in the website.  So users can also click just below the minimize button and drag the AT down so it takes up very little space.  When the user searches it doesn’t open to the original size anymore.

Another solution would be to set the initial size of the AT to be very small and make the use increase it in the App

Tim Jacobsen

~ Nick

Hi Robert,

Thanks a million for version 1.1.9 of your Enhanced Search Widget!!!

I tested your latest version this weekend. It rocks.

http://www.tapasdas.com/Maps/Phones/app26

PlanNet11.jpg

This magical widget wraps 4 essential functions - Identify, Search, Buffer, and Spatial Relationships - all under a simple, elegant and intuitive GUI that a lay person can figure out without having to read a help manual.

I am amazed to find how well it handles 49 Search Layers. The Parcel layer has around 1.6 million records.

PlanNet13.jpg

This was the most critical widget we needed for our migration to JavaScript. Your widget has delivered in spades.

THANK YOU!

Tapas

Tapas,

   It looks like I need to limit the dropdown max height. Wow I never thought someone would have 49 search layers. 

Robert,

I actually like it the way you have it implemented. The drop down list always fills up the available vertical space on the window. This means when I am working on a Dell 3007 UltraSharp 30 inch 2560 x 1600 monitor, I get to view the complete list of 49 search layers within the drop down without having to scroll.

On the other hand when I am working on a Dell U2412M UltraSharp 24 inch 1920 x 1200 monitor, I get the drop down list which still fills up the whole vertical space, but I have to use the scroll bar to get the bottom 10 layers. The example screenshot above is from a Dell U2412M monitor.

A drop down list which always fills up the available vertical space works better for me. It gives me a sense of having more breathing space. I would feel restricted if the list is limited to a finite number of lines like 10.

I guess this is a matter of perception. I would vote to leave it the way it is.

Thanks,

Tapas

Tapas,

   OK I was not able to tell from the image if the bottom of the Drop Down was going beyond the bottom screen edge. Go to know that it handles this. Does it still work OK for small mobile screens?

Robert,

No, the Drop Down never goes beyond the bottom of the screen.

Everything tested out ok on the iPhone 6 and iPad Air2 both in portrait and landscape mode.

What happens is that the drop down always extends to the bottom edge of the screen filling up the vertical available space. It never overflows. However, if there are more layers than what could be fitted into this vertical space, you just get a scroll bar. The user can scroll to get to the bottom of the list.

This is actually an elegant solution. The scroll bars appear only when necessary.

On a large monitor, if you shrink down the size of the window, and launch the app, the drop down stops at the bottom edge of the screen, never spilling beyond the bottom border.

Now, if it did spill beyond the bottom edge we would have had an issue.

So far, it works just fine and self configures gracefully on smart phones, tablets, and larger screens, presenting a scroll bar only when necessary.

Tapas

The "disable link if null" doesn't seem to be working has any body else had this issue? Or am I just missing something?

Cameron Johnsen

Cache County

GIS Specialist

435-755-1635

cameron.johnsen@cachecounty.org

>>> "Robert Scheitlin, GISP" <geonet@esri.com> 7/2/2015 1:39 PM >>>

GeoNet

Enhanced Search Widget Version 1.1.9 - 7/2/15

modified by Robert Scheitlin, GISP in Web AppBuilder Custom Widgets - View the full document

Live Preview Site

List of the latest enhancements and changes:

Added option to have limit search by map extent checked by default.

If there is only one search expression for a particular layer then the search alias drop down is hidden from the widget UI

Fixed a bug where drop down lists would hang on screen if the drop down was opened and the widget was closed before a list option was selected.

The maps popups are disabled now when using the graphical search draw tools.

When a layer is configured to set results to the attribute table and be added as an operational layer the widget now waits for the Attribute Table Widget to open before it attempts to zoom to the results.

Changes have been made to the interaction with the Attribute Table Widget to ensure better behavior.

Older enhancements or changes

Check the "Older enhancements or changes.txt" in the download for a complete list.

Comment by replying to this email, or go to the document on GeoNet

Create a new document in Web AppBuilder Custom Widgets by email, or at GeoNet

Following Enhanced Search Widget Version 1.1.9 - 7/2/15 in these streams: Inbox

This email was sent by GeoNet because you are a registered user.

You may unsubscribe instantly from GeoNet, or adjust email frequency in your email preferences

Cameron,

   My code checks for a actual null in the field data and a empty string "" If you have a " " (one blank space) then this is not considered null. Would this possibly be your issue?

This what the code looks like and I've attached an image of the field. The link still shows wether it is blank or

GeoNet

Enhanced Search Widget Version 1.1.9 - 7/2/15

new comment by Robert Scheitlin, GISP View all comments on this document

Cameron,

My code checks for a actual null in the field data and a empty string "" If you have a " " (one blank space) then this is not considered null. Would this possibly be your issue?

Reply to this email to respond to Robert Scheitlin, GISP's comment.

Following Enhanced Search Widget Version 1.1.9 - 7/2/15 in these streams: Inbox

This email was sent by GeoNet because you are a registered user.

You may unsubscribe instantly from GeoNet, or adjust email frequency in your email preferences

Cameron,

   No image is attached to your last post.

image2.JPG

Sorry about that.

I cannot find any spaces in the data. Do I need to change something in the code?

Cameron Johnsen

Cache County

GIS Specialist

435-755-1635

cameron.johnsen@cachecounty.org

>>> "Robert Scheitlin, GISP" <geonet@esri.com> 7/7/2015 11:16 AM >>>

GeoNet

Enhanced Search Widget Version 1.1.9 - 7/2/15

new comment by Robert Scheitlin, GISP View all comments on this document

Cameron,

No image is attached to your last post.

Reply to this email to respond to Robert Scheitlin, GISP's comment.

Following Enhanced Search Widget Version 1.1.9 - 7/2/15 in these streams: Inbox

This email was sent by GeoNet because you are a registered user.

You may unsubscribe instantly from GeoNet, or adjust email frequency in your email preferences

Cameron,

   So it looks like you have a mix of null and empty strings in your data. Are you getting a link for the both the null records and the empty string or just one and not the other?

You are the first to report this as not working and in my testing it is working fine so I am trying to see if I can narrow this down.

Yes it is happing for both the null and empty strings.

Cameron Johnsen

Cache County

GIS Specialist

435-755-1635

cameron.johnsen@cachecounty.org

>>> "Robert Scheitlin, GISP" <geonet@esri.com> 7/7/2015 11:37 AM >>>

GeoNet

Enhanced Search Widget Version 1.1.9 - 7/2/15

new comment by Robert Scheitlin, GISP View all comments on this document

Cameron,

So it looks like you have a mix of null and empty strings in your data. Are you getting a link for the both the null records and the empty string or just one and not the other?

You are the first to report this as not working and in my testing it is working fine so I am trying to see if I can narrow this down.

Reply to this email to respond to Robert Scheitlin, GISP's comment.

Following Enhanced Search Widget Version 1.1.9 - 7/2/15 in these streams: Inbox

This email was sent by GeoNet because you are a registered user.

You may unsubscribe instantly from GeoNet, or adjust email frequency in your email preferences

Robert,

Thanks for your widget, it is working great for us. One suggestion we keep getting is to have the ability to use the SQL Statement of 'IN' so users can search multiple items at once.

Is this something you are considering?

Zachary,

   I actually have code inside the widget to handle IN SQL statements, I just have not worked on the UI to enable configuration of this. So yes I am considering this.

Thanks for the response. Looking forward to enabling this capability in your widget.

Zachary,

   You can currently get an IN SQL expression to work if you manually change a "sqltext" property in the config_Enhanced Search.json.

Make sure to use a lower case in though. Here is an example: "sqltext": "UPPER(SITE) in '[value]'",

The user will have to enter text like 34-2,34-3,34-5 (for example).

Robert Scheitlin​ or power users like TAPAS DAS​ I have a question.

I have only used this widget once in one viewer on one service o far so I am kind of a newbie at it. Here goes.  I had it on Parcel 2014 service.  Well we now have a Parcel 2015 service. All the layers and even layer ids are the same except i just has a 2015 layer in it now.  So I switched my AGOL Arcgis.com map over to the 2015 service and removed the 2014 service. I did a find/replace all in eSearch and your Identify for 2014 changing to 2015 in the URL strings so it would point to the new service's URL. I relaunched WAB Builder.  When I go to add a new Expression, the attribute field name popup is blank. Restarted WAB several times, tried different browsers, same result. Has anyone else seen this?  I am on 1.1.9.

Hi Kevin,

This should be fairly easy to track down.

Could you please give us a copy of your config file for your eSearch?

Could you also give us an Item List of your Web Map on ArcGIS Online that lists all the data layers you are using.

It should be easy to match them up.

Thanks,

Tapas

Kevin,

Here is one thing you can try.

Remove the eSearch Widget, and then add the eSearch Widget back into your Web AppBuilder session.

This will essentially blank out the contents of the eSearch config file, and you will be starting fresh.

When you add the URL to your 2015 Parcel Map Service, make sure that you include the index number at the end of the string. It must always point to a specific layer ID for it to work.

For example, this will work:

http://gis.maricopa.gov/arcgis/rest/services/PlanNet/Basemap/MapServer/1

However, if you leave out the layer index, it will not work:

http://gis.maricopa.gov/arcgis/rest/services/PlanNet/Basemap/MapServer

Thanks,

Tapas

Hi Robert,

I would like to revisit the error message reported by Tim Jacobsen a few days back.

This is not an issue with your Enhanced Search Widget 1.1.9, but rather with the Attribute Table Widget from the Web AppBuilder Developer Edition 1.1 that your Widget connects to.

Nevertheless, I would like to bring this up because this is going to affect everyone of us using your Enhanced Search Widget.

The problem is easily reproducible 100% of the time.

To illustrate the issue, I have made 2 test cases - app32, and app33.

The first one works flawlessly while the second one throws an error.

Case-1: Enhanced Search Widget 1.1.9 without the Attribute Table.

This one works perfectly fine all the time.

Open app32

http://www.tapasdas.com/Maps/Phones/app32

Open the Enhanced Search Widget and search for the example Parcel Number = 16916033A

p01.jpg

The correct attributes are listed in the Results Pane.

p02.jpg

Next, try a search by Owner Name

p03.jpg

Enter the example Owner Name (Last Name, First Name) = Smith John

p04.jpg

112 matches are returned

p05.jpg

Next, try a search by Address

Enter the example Street Name = Dynamite

p06.jpg

233 matches are found

p07.jpg

Everything works flawlessly under Internet Explorer 10, 11, Chrome, Firefox, and Safari.

Now let's examine Case-2: Enhanced Search Widget 1.1.9 + Attribute Table.

The only difference is that I have enabled these two options:

Add Result as Operational Layer

Show in Attribute Table Widget

p08.jpg

To reproduce the error, you must use Chrome as your browser.

First you would need to clear our your Browser Cache by entering <Shift><Ctrl><Del>

Next, launch app33 in Chrome:

http://www.tapasdas.com/Maps/Phones/app33

Turn on Developer Tools in Chrome.

p09.jpg

There are no errors to start with.

p10.jpg

Search for the example Parcel Number = 16916033A

p11.jpg

The Attribute Table opens with the Busy Cursor

p12.jpg

After an annoyingly long wait, the Attribute Table does get populated.

However, the Console Window in Developer Tools throws this error:

Uncaught TypeError: Cannot read property 'geometry' of undefined

p13.jpg

These are the details:

p14.jpg

It appears this is something that Moxie and this team needs to address.

Try a Search for Owner Name containing "Smith John"

p15.jpg

Once again you get the busy cursor, and after a long wait the Attribute Table gets populated.

p16.jpg

However, you get the exact same error message:

Uncaught TypeError: Cannot read property 'geometry' of undefined

p17.jpg

You can ignore these errors. The app does work, albeit with a slow response time.

Now here is the curious part.

You can perform as many Graphical Searches you like. There are no errors!

p18.jpg

Also, the Attribute Table gets populated almost instantly during a Graphical Search. There is no lag.

p19.jpg

Robert, I know that you did not design the Attribute Table Widget. Your Enhanced Search Widget is simply displaying the Search Results through the built-in Attribute Table Widget in the Web AppBuilder.

The Attribute Table Widget is the weakest link in the Web AppBuilder. I wish someone would recreate the awesome Data Grid you had in your Flex version of the Enhanced Search Widget.

Thanks,

Tapas

Tapas,

   Can you try something for me? open the widget.js and about line 1571 find this if statement :

       if(this.autozoomtoresults){

          setTimeout(lang.hitch(this,function(){

            this.zoomall();

          }), 300);

        }

Change the 300 to 600 and test again.

Hi Robert,

Thanks for your super fast response as always!

I tried your change on widgets\eSearch\Widget.js

p20.jpg

I cleared my browser cache with <shift><ctrl><del> in Chrome and reloaded app33:

http://www.TapasDas.com/Maps/Phones/app33

When I ran the Attribute Search for Parcels, I still got the same error message in the Console Window for Developer Tools.

Note: If I do not clear my browser cache, and reload the page a second time, and run the exact same attribute search, the error message does not come up.

However, running a new Attribute Search like Parcel Number = 1691603 will again trigger the error message.

Thanks,

Tapas

What is the best way to upgrade to a new version with out having to re-create and relink your layers in e-search widget? replacing the eSearch folder in stemap/widgets makes you redo the widget and takes time.

Awesome widget!

2CDSD 2C,

For Existing apps:

   What you would want to do is replace the eSearch widget folder in your deployed app

[install dir]\server\apps\[app#]\widgets\eSearch

after you have done that then go configure the app in app builder and open the eSearch widget config UI and change something (so that it writes any new properties to the json).

For new apps:

   Do just as you already are doing just overwrite the eSearch widget in the stemapp.

Hi Robert,

We received a tip from ESRI to replace the LIKE operator with the "=" operator to improve response times with the Attribute Table.

I made another test case = app34

I also changed the setTimeout value from 300 to 2400 as a test in the eSearch\Widget.js file on line 1574

pic01.jpg

I opened Chrome and cleared my browser cache with <Shift><Ctrl><Del>

pic02.jpg

I launched app34 in Chrome:

http://www.tapasdas.com/Maps/Phones/app34

The Search Layer = Parcels, uses the "=" operator.

pic03.jpg

I opened the Console Window in Chrome Developer Tools.

There are no errors at this point.

pic04.jpg

I ran the example Search:

APN = 16916033A

The correct result appears in the Results Panel very quickly.

pic05.jpg

Next, an empty Attribute Table appears with the spinning wheel.

pic06.jpg

Next, the error message appears in the Console Window.

pic07.jpg

Finally, the correct attributes are displayed in the Attribute Table.

pic08.jpg

Note:

If I rerun the exact same search a second time without emptying the cache, no errors are returned.

If I run a new search with another APN value for example:

APN = 16916033B

APN = 16916034

the error comes back.

Conclusion:

Increasing the setTimeout value or replacing the LIKE operator with the = Operator did not help to remove the Error Message:

Uncaught TypeError: Cannot read property 'geometry' of undefined

Hi Robert,

I have a simple enhancement request that will solve our problem with the Attribute Table right away.

The real reason we like to have the results displayed in the Attribute Table is because of the nifty Export to CSV option. This is a powerful feature.  It allows us to view the results in Excel, make charts, reports, and perform further analysis.

p01.jpg

The Attribute Table also allows us an easy way to sort the columns. However, this can be done easily in Excel.

So if the Export to CSV function is the only real requirement, would it be possible to add this option directly on your Results Pane?

Here is a mockup of how it may look like:

p02.jpg

If we can get this option on the Results Pane, and the Export to CSV captures all the fields that are shown in the Popup, then we won't have any need to display the Attribute Table.

We can completely bypass the Attribute Table, and enjoy faster performance, and more screen real estate to display the map.

It would also be wonderful to have this Export to CSV option on your Identify Results Panel as well.

In the Flex version of your Identify Widget, you had a Copy to Clipboard option which we found very useful.

http://www.tapasdas.com/Maps/Desktops/web37

p04.jpg

If you could give us an Export to CSV option on the Results Panel of your eSearch and Identify Widgets, it will immediately solve our issues.

Thanks,

Tapas

Tapas,

   I have some ideas on the Attribute Table issue that I will try soon. I will consider the export to csv as well. As far as the ability I had in the Flex verion of the identify for copy to clipboard this is going to be something that is restricted in JS. Flash ran in a browser plugin so it had access to more things than JS like the clipboard. JS has no or little liberty to put something on the clipboard.

Robert,

That sounds great!

I appreciate all your enhancements and new features.

Hi Robert,

We got another tip from ESRI that may explain why we are getting this error.

Uncaught TypeError: Cannot read property 'geometry' of undefined

They explained that the zoomall function is getting invoked before the queries are coming back from the server.

The setTimeout value in milliseconds is there to delay the calling of the zoomall function allowing sufficient time for the results to be returned.

Line 1574 on file widgets\eSearch\Widgets.js

p01.jpg

The default value was 300 milliseconds. This delay is enough for most scenarios.

However, we are making searches on the Parcels Layer with around 1.6 million records.

It can take around 12 seconds for the results to appear.

So until this 12 seconds have elapsed, the array this.currentLayerAdded.graphics is empty.

Line 1280 on file widgets\eSearch\Widgets.js

p02.jpg

So when the zoomall function tries to read the first item of this empty array, it throws the error.

The trick will be to add the necessary logic to make the call to the zoomall function to wait until the array is populated.

If the wait time is based on a fixed delay value like 300 or 600 milliseconds, it will be a hit and miss scenario. One cannot anticipate the size of the database being queried.

This makes the solution complex.

Perhaps the delay time can be a user defined value tied to a specific layer.

Perhaps there could be a way to check to see if the array is empty before calling the zoomall function.

Thanks,

Tapas

Tapas,

   This is the same thing I have found and I am working on a fix that would not involve any additional user configuration.

#winning Robert & Tapas. Thanks for all your efforts both.

Ah and Tapas yes it worked fine when I cleared out the widget and put a fresh copy in. Who knows, maybe caching or something. But updating is now seamless and working.

Thanks Robert!! I would be looking forward to testing your next version.

Thanks Kevin for letting me know that you got the eSearch working after a fresh install.

Hey Robert,

I love your widget and have used it in the flexviewer and in the javascript WAB.  I was wondering though if the options from the flexviewer version where you could add a new search to a previous search and where you can use the graphical search and the text search together would make an appearance in the javascript WAB?  Or if they are there and I might have overlooked them?

Brady,

   Yes you will eventually see those added to the WAB version they just have not be a priority yet.

I am not sure what you mean by "and change something". what would one change?

Anything in the widget configuration UI (i.e. name of the search layer, symbology any of the options) just so that WAB recognizes a change and enabled the save button.

I can not see the attributes in query query donWAB ...
because it can be? any solution to this?

Thanks!

Luciana,

   This occurs when there was an error building the dropdown list for your search layer. What does the web console say your error is?

It does not fail, not the search attribute appears therefore the query can not perform and do not know why ...

which may be the problem with this?

Luciana,

  Again, this would not occur unless there was an error setting up the search Layers dropdown list. So there will be an error in the browsers web console.

Version history
Revision #:
5 of 5
Last update:
3 weeks ago
Updated by: