Hirdetés
- Real Racing 3 - Freemium csoda
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sz_gabor: Xiaomi porszívó magyar hang.
- Cifu: Űrhajózás 2025 - Összefoglaló írás
- eldiablo: 30 év után szakítottunk, de azért még beszélünk...
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- GoodSpeed: Samsung Galaxy A56 5G
Új hozzászólás Aktív témák
-
thon73
tag
Köszönöm!
A gond csak az, hogy még mindig nem értem a használatát. Ezt vajon a View állítja be, ha nagyobb akar lenni, mint a Parent által adott érték? És akkor a Parent mit tesz? Tudomásul veszi, vagy küld nagyobb értéket? (Gondolom, ez nincs felprogramozva, csak a logikát kérdem.)A konkrét probléma lényege:
A parent egy frame-layout, amit a rendszer ad a KeyboardLayout számára, nem tudom megváltoztatni.
A Custom View magassága (alapvetően a rendelkezésre álló szélességtől függ), de ami fontos: nem haladhatja meg a rendelkezésre álló magasság egy bizonyos százalékát. Ez idáig egyszerűnek tűnik.
DE!
A mérési ciklus során egy csomó onMeasure() hívást kapok, melyek némelyike a teljes magasságot, némelyike a Navigation Bar-ral csökkentett magasságot, némelyike a már számított magasságot, némelyike pedig az általam számítottnál is kisebb magasságot kap meg - persze mindig AT_MOST megjelöléssel.
Hozzáteszem: a Custom View onMeasure metódusa MINDIG egy fix magasságértéket ad vissza - ami viszont természetesen nagyobb, mint fent a negyedik érték.Itt vált gyanússá, hogy használnom kellene ezt a bizonyos bitet. De akár beállítom, akár nem, ugyanaz történik. Pedig ettől reméltem a megoldást.
A hibajelenség (lehet, hogy ettől független): A Custom View tényleges magasságmérete némileg random értéket vesz fel. Néha pontos, fekvő módban néha "odaképzeli" maga alá a Navigation Bar-t (ami egyébként oldalt van), álló módban meg néha becsúszik a Navigation Bar mögé. Tíz esetből kb 1-2 alkalommal hibás, holott a logika mindig ugyanaz. És csak elforgatás után jelentkezik a hiba, ha requestLayout()-ot kérek, akkor pontosan számol.
Sehol nem találtam ilyen hibáról leírást, és elképzelni sem tudom, mit csinálok rosszul. A teljes program túl nagy, kellene írni egy rövid tesztet, de ahhoz se kedvem, se időm. Vagy a rendszerben van a hiba, az is lehet. Bocs, hogy hosszú voltam, de tényleg a fejem verem tőle a falba.
Közben rájöttem, hogy megkerülésül minden elfordítás (és measure cycle) után kiadok egy requestLayout-ot, ami rendezi a View-t. De valószínű nem ez a korrekt megoldás.
Új hozzászólás Aktív témák
Hirdetés
- Real Racing 3 - Freemium csoda
- exHWSW - Értünk mindenhez IS
- Hálózati / IP kamera
- Milyen billentyűzetet vegyek?
- Teljes verziós játékok letöltése ingyen
- Google Pixel topik
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- Kecskemét és környéke adok-veszek-beszélgetek
- Építő/felújító topik
- További aktív témák...
- ÁRGARANCIA! Épített KomPhone Ultra 9 285K 64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- Apple iPhone 13 / 128GB / Kártyafüggetlen / 12Hó Garancia / Akku: 100%
- HP ProDesk 600 G5 i3-9100 8GB 256GB 1 év garancia
- Bomba ár! HP ProBook 430 G3 - i5-6GEN I 8GB I 256SSD I HDMI I 13,3" HD I Cam I W11 I Garancia!
- iPhone 15 Pro 128GB 100% (1év Garancia)
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: Laptopműhely Bt.
Város: Budapest

