xamarin/Xamarin.Forms

Xamarin listview when loaded inside secondary view of SfNavigationDrawer doesn't display in view completely

Ouverte

#5 889 ouverte le 11 avr. 2019

Voir sur GitHubGuide contributeur
 (6 commentaires) (0 réaction) (0 personne assignée)C# (1 926 forks)batch import
a/listviewe/4 :clock4:help wantedinactivep/Androidp/UWPpartnert/bug :bug:up-for-grabs

Métriques du dépôt

Stars
 (5 644 étoiles)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

Description

When you open secondary drawer, there are totally 3 items but only one comes in view in portrait mode. If you change device orientation to landscape mode then all 3 items loaded completely. Can you please check the reported issue in while loading initially in portrait mode. Not sure about issue in

Steps to Reproduce

  1. Open primary NavigationDrawer
  2. Tap MoBaViewer1
  3. Now open secondary navigation drawerUWP & iOS.

Expected Behavior

Three items loaded in xamarin listview should display fully in view.

Actual Behavior

Three items loaded in xamarin listview doesn't display fully in view.

Basic Information

  • Version with issue: 3.6.0.293080
  • Last known good version:
  • IDE: VS 2017
  • Platform Target Frameworks:
    • Android: 8.1 API 27
  • Android Support Library Version: 27.0.2.1

Reproduction Link

http://www.syncfusion.com/downloads/support/directtrac/general/ze/SIMPLE~1-43228028

Guide contributeur

Direction de recherche
Étudiez le comportement de mise en page de ListView à l'intérieur de SfNavigationDrawer lorsque le tiroir est ouvert en mode portrait. Vérifiez si le problème est lié à la mesure de la hauteur ou aux cycles de mise en page. Le lien de reproduction (http://www.syncfusion.com/downloads/support/directtrac/general/ze/SIMPLE~1-43228028) peut contenir un exemple de projet. Consultez les commentaires #1 #6 pour toute information supplémentaire. Concentrez vous sur l'interaction entre le tiroir et le rendu de la listview.
Stack technique
csharp
Domaine
mobile
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
C#Xamarin.Forms
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65