Is functioneel "bottom anchoring of linked portals" mogelijk?

[Gido_]

Sorry, kon het in het Nederlands niet gezegd krijgen...

Voor eigen gebruik ben ik fan van monsterpickers.

Dit zijn bij mij dan bv. 10 kolommen van eigenlijk één portaal, waarbij ik de Initial Row 9 keer aanpas.

Ben ik correct dat wanneer je al deze portalen "bottom anchor"t, dat FM niet zo slim is om de flow bij stretching correct te maken, of mis ik een "truukje"...?

Is hier ...

- iets dat ik beter in de manual moet zoeken?

- Zo nee, een geniale workaround?

- Mogelijk met een plugin of dergelijke?

- Niet mogelijk in FM 12, maar wél in latere versie...?

[menno]

Ik weet niet exact wat je zoekt, maar je zou het op de bijgaande manier kunnen oplossen. 

SpecifiekePortals.fmp12

[menno]

Met GetLayoutObjectAttribute ( objectname ; "Height" ) kan je de hoogte van je portaal meten en delen door de hoogte van een rij. Dan weet je het aantal rijen dat van de portaal hoog is.

Dat getal kan je invullen en dan daarmee kan uitrekenen welke records je in de gekoppelde 2e portaal zou moeten tonen. Helaas is er in FM12 geen script-trigger aanwezig om dit dynamisch tijdens het wijzigen van de hoogte van je venster te verwerken. Vanaf FM13 kan je een script-trigger "OnLayoutSizeChange" gebruiken, maar daar heb jij niks aan.

Je kan wel "OnLayoutEnter" gebruiken, die is in FM12 wél beschikbaar, maar dan werkt he alleen wanneer je naar de layout toegaat en niet wanneer je de grootte van je venster aanpast. Ik heb dus wel een voorbeeldje toegevoegd maar dat werkt het beste vanaf 13.

DynamischePortals.fmp12

[Banach]

Je geeft de initial row een vaste waarde. Deze is echt vast, dus statisch en FM handelt daarnaar. Verder heeft FM geen weet van andere portalen met dezelfde TOC maar andere initial row.

[Gido_]

"Geen weet," zou ik niet zeggen... Men heeft het gewoon niet ingebouwd dan. Als je nu bv. een $ aan de initiële waarde kon voorvoegen als hint dat het boeltje moet flowen...

Mss toch eens op een groot forum vragen. Als je nl. de lengte van een portaal kan detecteren (ik dacht van wel), dan is volgens mij ws een "geniale" hersortering mogelijk van de waarden, zodat alles toch klopt. Mss iets voor Maikhail Edoshin als die nog actief is?    Petrowsky heeft wel een Russische naam maar gaat er ws zijn kop over breken... ?  Mss geraak ik er zelf ook. Gewoon starten van piepkleine portaaltjes. Is mss "veel simpeler dan je denkt."

Edited May 21, 2018 by Gido_

[Gido_]

1 hour ago, menno said:

Ik weet niet exact wat je zoekt...

Maw..., je weet dat een portaal kan auto-stretchen naar onder, maar dit lijkt niet te werken voor meerdere (gelinkte) portalen op diezelfde relatie.

Ttz, alle portalen kunnen mee-stretchen, maar de inhoud reflowt niet (Initial Rows blijven gerespecteerd). Ik zou dit bij versie nr zoveel toch al lang opgelost hebben als ik FM was. Kan niet zo moeilijk zijn. Maar ja, de aandacht is mss meer naar web-toepassingen gegaan, en daar is dat minder gewenst of mogelijk.

Ik vermoed ondertussen dat je niet het aantal fysieke lijnen van één portaal kan tellen (niet de Count dus), tenzij je op de laatste rij klikt, of een zeer riskante opzet maakt waar je mss net erop of ernaast kan zitten door een berekening met schermhoogte. Ik zal voor mezelf dan maar gewoon een extra layout maken ws, uiteindelijk. Maar kan me toch goed voorstellen dat anderen dat ook interesseert voor de wat grotere pickers, ook al zijn ze maar 2 (gelinkte) portaalkolommen ipv 10.

Edited May 21, 2018 by Gido_

[Gido_]

On 5/22/2018 at 9:20 PM, menno said:

Met GetLayoutObjectAttribute ( objectname ; "Height" ) kan je de hoogte van je portaal meten en delen door de hoogte van een rij. Dan weet je het aantal rijen dat van de portaal hoog is. [...]

Excuses voor de late reactie...

Goeie hints weer, bedankt Menno! 

Ondertussen vermoed ik dat het toch beter is het professioneel aan te pakken met voorselectors of zo. Want ook een monster picker voor mezelf raakt op de duur waarschijnlijk weer vol, en dan moet het er tóch van komen...