Dropdownheight does not seem to have any effect AND why strange search behaviour

[john murray]

1) I am using 4 autocomplete controls on a IOS/ANdroid/UWP

currently this is happening on UWP - havent finished testing others

the lower two autocomplete controls are very close to the popup keyboard and the 'dropdownbox' positions above the textbox control

this means that the top item on the top item on the list is always obscure by the toolbar

I have tried setting maximumdropdownheight  but this simply seems to cause the dropdown not to appear whatever value I set it at 

Is there any way of setting a limit on the items in the dropdown?  that would solve it for me as the required item is invariably in top two or three items

Another issue is this 

the list is a list of places and their 4 letter Icao codes - for example EGHH Bournemouth 

if one types in Bour - the drop down suggest the correct entry but if you continue typing Bournem  - the  drop down is empty even though the datasource does have a record containg Bournem

This seems like a bug to me 

[Victory Jessie Selvam D]

Hi John,

Thank you for using Syncfusion products.

We have checked the reported issues "MaximumDropDownHeight is not working" and "Suggestions are empty after typing Bournem which is available in data sources" in Xamarin.Forms UWP using v15.1.0.37 and we were unable to reproduce both the issues.

We would like to inform you that suggestion box will always open at the specified SuggestionBoxPlacement only if there is enough space at that placement position. Otherwise it will open at the placement position(top or bottom) where there is enough space for the list.

We suspect that after setting MaximumDropDownHeight property, suggestion box has got enough space to open at bottom(default SuggestionBoxPlacement is Bottom) and it opened at bottom. It is then overlapped by keyboard and it seems to be setting MaximumDropDownHeight does not open the suggestion box.
Also while entering character "B" suggestions count is huge, due to space unavailability suggestion box opened at top. After entering "Bournem", suggestion count is 1 and suggestion box has got enough space to open at bottom(SuggestionBoxPlacement is Bottom) and it opened at bottom. It is then hidden by keyboard and seems like suggestions are not filtered.

We suggest you to use SuggestionBoxPlacement as Top for SfAutoComplete if the control is positioned at bottom of screen and pushed by the on-screen keyboard during focus. Also, set the MaximumDropDownHeight value based on the available height for suggestions box. Please find the sample prepared from our side to check the reported issues and screenshots of output from the following link:

Sample: AutoComplete_DropDownHeight_Filter

Screenshots: Screenshots

Please get back to us with modified sample reproducing the issues along with replication video if we have misunderstood your query.

Regards,
Jessie

[john murray]

many thanks Jessie

first of all Homage to you and your team you always seem to be very thorough and come back quickly - I wish Xamarin was as good 11/10

I slightly beg to differ - if you get the dropdownheight wrong and the position 'top' then the selection box with your most likely at the top will disappear into the tool bar

however you are right about the second problem

I have got around it all by setting drop down maximum height to half the screen height and position the lower autocompletes with drop box on top and vice versa

Can you answer the following questions pls

1) what is the unit of measurement for dropdown item height - is it dpi or pixels

2) what does dropdown item height change  ? doesn't seem to change much as far as I can tell

3) is there any way of changing the row spacing in the drop down box?

4) why on an emulator with a similar resolution to a real device does one setting for drop down or text height appear vastly different

     as a subsidiary question on that - one would have expected the same value for an entry box to produce the same font size result on the autocomplete box - it doesn't SFautocomplete appears to require much bigger values - heance the question are we dealing with dips or pixels  very confusing

anyway just the same many thanks again

[Victory Jessie Selvam D]

Hi John,

Thank you for your update.

The MaximumDropDownHeight values are pixels and it should be computed based on the bounds of content, on-screen keyboard to avoid disappearing into the toolbar. We have prepared a sample for the same and in the sample, we have computed maximum dropdown height in CustomPageRenderer class of UWP project and set it to MaxDropDownHeight property of SfTextBoxExt control. You can download the sample from the following link:

Sample: 129207_-_AutoComplete_DropDownHeight_Filter

The unit of MaximumDropDownHeight, DropDownItemHeight and TextSize are pixels in SfAutoComplete. DropDownItemHeight property is used to change the height of items in drop down list. Currently DropDownItemHeight property is not working in UWP and we have logged a defect report for it. The fix for this issue will be available in our upcoming 2017 volume 1 service pack 2 release which is expected to be rolled out in the end of March 2017.

We have compared the AutoComplete Text and DropDown in both "Nokia Lumia 650 5 inch" device and "720p 5-inch Mobile Emulator" and we could not find vast differences. Also, we have checked FontSize value to 20 in Entry and SfAutoComplete controls, both appeared to be similar and the screenshots are given below for reference. Please get back to us with the device, emulator details along with screenshots highlighting this issue so that we can proceed further on this.

Screenshots: Screenshots

Regards,
Jessie

[john murray]

thanks again Jessie

I have moved on from trying to figure why the toolbar was obscured - probably my code and the way I was handling padding 

Anyway a further issue arises 

on the Android (in this Pcl) setting the drop down text and textsize by way of setting a style has no effect

I have been working in Dip so I created a dependency service to give me the pixels 

those pixels are about right - so I put them in the style for all my SFautocomplete boxes but none responded until I specifically wrote 

mySFautocontrol.Textsize = 44 // or whatever was the appropriate pixels 

is it true one cannot set the textsizes in a style object?

[Vanaja Annasamy]

Hi John,

Thank you for your update.

We can set the DropDownText and DropDownTextSize using style object in SfAutoComplete. We have created sample with your requirement and please download the same from below link.

Link: http://www.syncfusion.com/downloads/support/forum/129207/ze/AutoComplete883591493 

Please let us know if you have concern on this.

Regards,
Vanaja R.A.
 

[john murray]

Hi Vanaja

I tried that solution and have spent all day with the usual XAmarin nonsense of various versions being incompatible - updating nuget simply stalled

various tweaks and working on three different computers later all I can report is that 

1) yes your solution produces a drop down box with a resonable size font using a style

2) BUT !!!! as I said at the beginning I am NOT using XAML  - when I adapt your code and try to do what you have done in c# I have yet to be able to get it to work   - 

3) I got the original to work on emulator and a real machine and, leaving aside the issue of Style,  setting the font to 20 produces vastly different results on hte xxhdpi emulator compared with a sony z3 with hdpi

I will continue to experiment but it would seem there is something wrong with setting the font inside a code behind stlye - unfortunately I've had so many problems with xamarin and emulators that I am no further forward 

[john murray]

I am struggling with this

the Autocomplete box seems to need a vastly different number for Textsize and droptextsize one one machine compared with emulators

For example   on a real machine Sony Z3 with xxhigh as its declared density (Displaymetrics.Densitydpi = 480)  and (Displametrics.Density= 3)   screen height in px 1778

compared with an xxhdpi  emulator of similar screen size (1788) and similar density dens = 2.75 densitydpi = 441

On the real machine Sony Z3 one can set the autocomplete textsizes to similar to the normal entry box size as derived from

 editsize = (int)Device.GetNamedSize(NamedSize.Medium, typeof(Label));

this actual resolves to an editsize of about 18 on the emulator and 16 on the Z3

However on the emulator an autocomplete set to such sizes is so small as to be nearly unreadable whereas on the Z3 if anything the size is too big (i.e. it renders larger than the native Entry)

As these are very similar screen sizes and densities there is no explanation in using some sort of scaling factor - it  is the peculiar way Syncfusion deals with text size

Can you suggest a solution? 

Is it that all real machines will render sizes much bigger than the emulators - if so I cant go our and buy a load of Android machines to test it. If the emulator is a real reflection of how textsize is rendered in autocomplete on a real world machine tehn why does my real world Sony show huge  textsizes in autocomplete when set to a sze which is redable on practically the same screen size and density emulator??????

[john murray]

I have a vs2015 solution which demonstrates the problem    -  cannot upload it here because your limit is 30mb and the full solution is 96mb compressed - I can send a drop box link if youd email me 

to be visible on a real  life sony Z3 the autocomplete textsize needs to be set to Device.NamedSize.Micro  (or 10 if you prefer) 

as it happens this setting works also on a tablet - the fontsize 10 actually renders largeer than an entry box set to the same size

leave this 

and then run it on any emulator and the autocomplete box is too small to be readable

this is true of all the emulators I have  a 5" 5.5" and 7" runing Android 4.2 and 6

BTW I have found out  why setting font in style in code behind SEEMS not to work - if one passes a value say from Android display metrics this may turn out to be a double with decimal places

if such a figure is passed to Style then it is ignored unless it is an integer so it always defaults to 10 - giving the impression that Style does not work

[Vanaja Annasamy]

Hi John,

Thank you for contacting Syncfusion support.

Query: DropDown TextSize vary in different device in SfAutoComplete

We were able to reproduce the reported issue " DropDown TextSize vary in different device in SfAutoComplete" at our end. We have logged a defect report regarding the same. A support incident to track the status of this defect has been created under your account. 

Please log on to our support website to check for further updates.

Link: https://www.syncfusion.com/account/login?ReturnUrl=%2fsupport%2fdirecttrac%2fincidents/  

Regards,
Vanaja R.A.