Begeleidende tekst knop

[Dirty May]

Best mogelijk dat ik er over zie, maar kan ik onder FM12 nog een tekst definiëren die verschijnt als men de cursor over de knop beweegt ?

[Rik Verbruggen]

Hallo Dirty,

Dat kan volgens mij als volgt:

- Open het infovenster (bv m.b.v. menukeuze 'Weergave/Infovenster')

- Kies tabblad 'Positie'

- Daar kun je jouw tekst kwijt in het veld 'Knopinfo'.

Hoop dat dit helpt.

Rik

[Dirty May]

Bedankt Rik !

 

Dat is het dus inderdaad.

Maar ben ik de enige zeur die

de plaats daarvan wat onlogisch vindt ?

 

En via Help kwam ik er ook niet uit.

Als je niet specifiek 'Knopinfo' ingeeft krijg

je bij 'Knop' niets terzake, noch enige verwijzing.

 

Plus daarbij : Te lang vorige versies gewoon geweest.

 

Marc

[hbrendel]

De Nederlandse vertaling is hopeloos. In het Engels is het 'tooltip'. Dat weet iedereen.

Er zijn meer vreemde vertalingen. Ik raad iedereen aan om in het Engels te werken.

[Rik Verbruggen]

Hi Marc,

Ik ben nog niet zo lang geleden overgestapt uit een heel andere omgeving, met classes en inheritance, properties, methods en events. Een hele andere wereld maar wel één waar je echt alles zelf moest regelen. FM is ontzettend wennen voor me en veel dingen vind ik gekunsteld en inderdaad soms niet erg logisch. Maar dat zal voor ieders beleving anders zijn. Er is bijvoorbeeld wel een scriptstap 'Portaalrij verwijderen maar naar de scriptstap 'Portaalrij toevoegen' kun je lang zoeken . En zo zijn er nog veel meer dingen die ik mis of anders zou willen maar... aan de andere kant zijn er in FM verschrikkelijk veel dingen standaard geregeld voor je. Het is multi-user, web-enabled, gebruikersbeheer is aanwezig en nog een aantal andere dingen die het leven makkelijker maken. Zoals gezegd mis ik nog een aantal praktische dingen voor het wow-gevoel maar ik zie wel de potentie van FM. Zit met smart op versie 18 te wachten.

Kortom: hier vind je wat, daar laat je wat. Ik kijk maar naar het saldo van alle minnen en plussen en kom dan toch positief uit.

Rik

[Felix]

.

Edited October 4, 2015 by Guest

[Dirty May]

Ik ben over het algemeen vrij tevreden met FM.

 

Van in den beginne, zelfs nog in de prehistorie ervan,

ik dacht dat het toen nog naar 'Claris' luisterde, was ik er al bij.

 

Alleen, omdat het bij mij enkel om hobbymatig en huishoudelijk

gebruik gaat, en er dus niet fulltime mee bezig ben,

mis ik soms wat evoluties of nieuwe concepten.

Dat noodzaakt soms wat tot extra research.

Maar daar kan ik mee leven.

[hbrendel]

Ik raad iedereen aan om in het Engels te werken.

Dat willen mijn klanten niet.

Ik bedoel ontwikkelen met FMP Advanced Engels. Je klanten hebben FMPro NL en je interfaces en custom menus zijn ook NL.

 

Uiteraard...

[Felix]

.

Edited October 4, 2015 by Guest

[Rik Verbruggen]

Ik wil hiermee aangeven dat 'Portaalrij verwijderen' en 'Portaalrij toevoegen' twee zodanig verschillende acties zijn dat de logica eenvoudigweg niet toestaat dat de laatste als scriptstap beschikbaar zou zijn.

 

Waar ik eigenlijk op doel is het volgende:

Via de relatie tussen twee tabellen is het mogelijk om aan te geven dat een portaalrij toevoegen via de relatie is toegestaan (optie 'Maken van records in deze tabel toegestaan via deze relatie'). Dan verschijnt er steeds een extra blanco regel in de portaalrij die allen maar ingevuld hoeft te worden om een nieuw record toe te voegen. Wat mij betreft zou de scriptstap 'Portaalrij toevoegen' alleen maar de blanco regel zichtbaar maken als bij de relatie tussen de tabellen is aangegeven dat het maken van nieuwe records via de relatie niet is toegestaan. Nu moet ik eerst een andere lay-out openen waar de tabel van de portaalrij de hoofdtabel is, daar een record toevoegen en vervolgens weer terugkeren naar de originele lay-out. Dat heeft dan weer als gevolg dat direct allerlei scripttriggers worden geactiveerd en dat is in mijn beleving niet altijd gewenst.

We dwalen wel wat af van het originele onderwerp maar ik ben benieuwd hoe anderen dit zien,

Rik

[Felix]

.

Edited October 4, 2015 by Guest

[Rik Verbruggen]

Hi Felix,

Bij methode 1 wordt de blanco/lege regel toch getoond? Of zie ik dat niet goed? Dat is de methode die ik niet zo prettig vind. Ik heb al oplossingen gezien met een 'portalrowbutton' waarbij er een knop over de laatste portaalrij ligt die dan met voorwaardelijke opmaak zichtbaar dan wel onzichtbaar wordt gemaakt. Maar de scriptstap 'Portaalrij toevoegen' zou al dat gedoe in één elegante stap oplossen dacht ik.

Daarom gebruik ik methode 2, zelfs precies zoals jij zegt. Ik heb als gewoonte om standaard voor iedere tabel (wat ik zelf dan maar noem) een 'browse-laytouts' te maken. Dat zijn lay-outs (in tabelweergave) met alleen de tabelvelden zodat ik altijd even snel in een tabel kan neuzen. Als ik een record moet toevoegen in een portaalrij spring ik daarnaartoe, maak het record aan en ga weer terug naar de originele lay-out. Het probleem is daarbij niet de triggers in de 'browse-lay-out' (daar staan helemaal geen triggers in) maar de triggers in de tabel vanwaaruit ik de jump maak naar de browse-lay-out.

Rik

 

Iedereen overigens een prettig weekend gewenst.

[Felix]

.

Edited October 4, 2015 by Guest

[Rik Verbruggen]

Zo doe ik het nu inderdaad. Iedere keer maar weer een variabele zetten en checken in het triggerscript of het script mag worden uitgevoerd. Gedoe wat eigenlijk helemaal niet nodig zou hoeven zijn. Onze gedachtenwisseling begon eigenlijk met dit onderwerp als voorbeeld. Als dit het enige was begon ik er waarschijnlijk niet eens over maar ik (jij/jullie ook waarschijnlijk) kan zo nog een aantal dingen opnoemen waarvan in denk; jongens (en meisjes ook natuurlijk), als FM daar nou eens net even wat meer werk van had gemaakt dan ... vul zelf maar in. Lijkt me ook niet zo moeilijk om daarover consensus te bereiken. Zeg nou zelf, wiet stemt er tegen het invoeren van de scriptstap 'Portaalrij toevoegen'?

Maar laat ik er verder maar over op houden. Ik voel me nu al bijna de zeur die Marc bedoelde .

Wel leuk om weer even van gedachten te wisselen. Stel ik op prijs.

Rik

[rmw]

Om nog even off topic te blijven (sorry Dirty May)

Is dit iets voor het invoeren van portaalregels?

 

rmw

[Rik Verbruggen]

Sorry rmw, ik was even uit de lucht. Zie je berichtje nu pas.

Dat is inderdaad ook een slimme manier. Bedankt.

Ik ga kijken of dit inpasbaar is.

Rik

[Rik Verbruggen]

***

Edited September 15, 2013 by Guest

[Rik Verbruggen]

***

[Theo Tromp]

Ik zie je punt. Zelf gebruik ik eigenlijk nooit layout triggers, maar je kunt ongewenste neveneffecten ondervangen door in je script een parameter mee te nemen of een variabele te zetten en die te checken in het script. Het hoeft dus allemaal niet zo'n probleem te zijn.

 

Dit kan ook worden opgelost door te springen naar een ander (verborgen en altijd aanwezig) window. In dat window worden alleen layouts gebruikt zonder triggers en kan je dus naar hartelust tussen de verschillende werk-layouts navigeren terwijl in je originele window niet van layout wordt gewisseld in scripts.

 

Het extra window wordt bij het opstarten van de applicatie al aangemaakt en kan niet worden gesloten door de gebruiker.

[e-bis]

Om terug te komen op het originele topic:

Ik werk met een vertaal-script waarbij ik $$ variabelen laat "vullen". Die variabelen gebruik ik vervolgens in het tooltip.

Op het beginscherm kan de gebruiker zijn taal kiezen waarna de vertaalscript wordt uitgevoerd en de juiste taal verschijnt wanneer met de muis over een veld wordt gegaan.

Hetzelfde doe ik met de namen van de velden zodat ik steeds maar 1 layout moet gebruiken onafgezien van de taal van de gebruiker.

Dat noodzaakt uiteraard wel de discipline dat je bij ieder nieuw veld dat je creëert, automatisch ook het vertaalscript verder aanvult.

 

 

 

Sent from my iPhone using Tapatalk - now Free