als developer van FM11 naar FM12

[jw]

Beste mensen, wie maakt het wat makkelijke voor me?

Mijn klanten werken met FM11, enkele nieuwe klanten heb ik in FM11 opgezet, en daar overvet naar FM12.

 

Want het layouten in FM12 vind ik maar niks.

- het markeren van objecten werkt onhandig

- het kopieren van beveiligde en onbeveiligde objecten sanen gaat niet

- het kopieren en slepen op de zelfde hoogte werkt niet

- de magnetische aansluiting bij het slepen wil ik niet zo

- de kleurenset is veranderd

- de pixels lijken aangepast, opeens iets met cijfers achter de komma

er is vast meer te ontdekken.

Werken jullie al allemaal blij met FM12?

[Felix]

.

3 oktober 2015 aangepast door Gast

[menno]

Het layouten is inderdaad ietsje minder, maar dat is denk ik toch ook een kwestie van wennen en gewoon niet zo'n hekel hebben aan veranderingen ... dat zit vooral tussen onze (dus ook de mijne) oren

 

Er staan echter heel wat voordelen tegenover:

ExecuteSQL: data opvragen buiten de context van Filemaker om, nog meer scripttriggers, triggeren in debug-mode uit kunnen zetten, op sommige punten duidelijk sneller dataverkeer tussen client en server etc.

 

Als je de fm-server inzet (ik doe dat bij 99% van mijn klanten), dan heb je een veel betere console waarin we nu eindelijk ook bestanden kunnen downloaden ipv alleen maar uploaden, progessive backup etc ....

 

er zijn nog meer voordelen, maar dit zijn voor mij de meest in het oog springen en al met al is eigenlijk alleen het layouten ietsje lastiger geworden .... ik wen er maar gewoon aan, want ik vind de voordelen belangrijker.

[Roger]

Ik werk zelfs nog in 10 waar de inspector (infovenster) nog een klein maar handig en doeltreffend venstertje was. Ik mis daar weinig. Themes interesseren me niet. Men doet het voorkomen alsof deze een wondermiddel zijn om oubollige layouts een moderne look&feel te geven. Zelf ben ik van mening dat juist het tegenovergestelde wordt bereikt. Alsof een theme ook maar in de buurt komt van de OS X look, om maar eens wat te noemen. Geef mij maar theme classic, designing doe ik zelf wel. En inderdaad, sinds 1992 klonen we objecten door ze aan te klikken en te verslepen, met de alt-toets ingedrukt over de x- of y-as. Wie bepaalt dat dit van de een op de andere versie niet meer mag en noemt dat vervolgens een upgrade?

 

En dit gaat dan nog slechts over het 'layouten'. Problemen ontstaan er pas écht na conversie van een complex .fp7 bestand naar het .fp12 formaat. Alhoewel ook hier geldt dat de problemen vooral layout-technisch van aard zijn. En nee, dat is niet één twee drie aangepast als je meer dan 100 layouts hebt.

 

Het is jammer dat FileMaker ervoor kiest om zo nu en dan naar een nieuw bestandsformaat over te stappen, al begrijpen we dat daar soms niet aan te ontkomen valt zoals van .fp5 naar .fp7. Toen werd de hele architectuur van het pakket omgegooid en opende zich een wereld aan nieuwe mogelijkheden. Weliswaar kon je maar het beste van scratch af aan opnieuw beginnen om in die wereld aangenaam te vertoeven. Laatst kwam ik er nog eentje tegen, een .fp12 op de leest van .fp5 met 25 losse bestandjes... wat een hel. Maar nu van .fp7 naar .fp12..... wat heeft ons dat nou helemaal gebracht? Containervelden met externe opslagmogelijkheid. Absoluut een superfunctie. Maar had die lekker in het oude bestandsformaat gestoken. Dat was écht wel mogelijk geweest. Immers, plugins van derden boden dit al.

[SuperWimmie]

Ach... ik accepteer gewoon alle veranderingen.

Er tegen vechten heeft geen zin, je hebt jezelf er mee te pakken.

Ik zit al sinds versie 3 op Filemaker en heb diverse malen de nadelen ondervonden van generatie overstappen.

Wat een werk, wat een gewenning. Vreselijk.

 

Maar eenmaal daar doorheen, kijk ik ook nog wel eens achterom.

Ik moet er ab-so-luut niet aan denken dat ik was blijven hangen in versie 3.

Dan was mijn onderneming kansloos.

 

Innovatie, dat kan alleen maar bereikt worden door verandering.

Verandering is voor mij een investering in de toekomst, het is een kans.

Filemaker verandert op zeer strategische wijze en ik groei mee.

Zo ervaar ik dat als ondernemer. Verandering zie ik als constante.

 

 

 

Maar goed, nu de problemen.

 

Markeren: Gebruik de Control toets tijdens het selecteren en je hebt de oude selectiemethode van versie 11 te pakken.

Wat heb ik zitten worstelen omdat ik dit niet wist...

 

Kopieren van beveiligde en onbeveiligde objecten: klopt, helaas...

 

Kopieren en slepen op dezelfde hoogte, magnetische selectie: helaas ook waar...

Ik heb wel een oplossing gevonden door links bovenin het scherm een vakje te plaatsen, die ik bij kopieren naar andere layouts ook steeds meeneem.

Hierdoor komt een gekopieerd object op de andere layout altijd op exact dezelfde positie terecht en werkt de magneet iets prettiger.

Zelf heb ik veel liever de oude grid van versie 11, zonder die maffe, verstorende magnetische functie... in 11 maakte ik strakkere layouts dan nu in 12...

 

Kleurenset gewijzigd:

Is dit nou echt een probleem? Eenmaal de layouts aangepast, zit je voor de toekomst nu wel via een CSS methode te werken. Let maar op, daar komen mooie dingen uit voort.

De oude 11 kleuren methode is teveel Filemaker. Alsof je op een eiland zit.

 

Pixels:

Is omgebouwd naar Punten. het lijkt er op, maar is niet hetzelfde. Kost dus werk.

Ja, ook hier moet je kijken naar CSS.

 

Themes:

Ik gebruik ook Classic. Is sneller en zelfs stabieler!

Maar veel eigenschappen waarop Themes zijn gebaseerd kan je ook in Classic opnemen.

Zo gebruik ik wel allerlei nieuwe eigenschappen in de layout, waardoor het veel moderner oogt.

Technisch en gebruiksmatig ondergeschikt, maar commercieel gezien echt belangrijk. Doorslaggevend zelfs.

 

Heb je dus kennis van hoe en wat CSS is (website bouwers herkennen dit) dan zie je de enorme potentie van de strategische keuze van Filemaker.

Ken je Filemaker IWP, dan poets je de nachtmerrie weg en blijft er een heerlijk hemelse droom over.

 

Om over de potentie van Filemaker Server nog even te zwijgen.

Ik spreek je over pakweg 10 jaar nog wel.

[Felix]

.

3 oktober 2015 aangepast door Gast

[menno]

ExecuteSQL: data opvragen buiten de context van Filemaker om

 

Jammer genoeg werkt dat niet op de FM DB zelf, maar heb je een ODBC koppeling naar elders nodig. Het nut zie ik dan niet zo, of er moet een truuk zijn om via SQL data vanuit dezelfde FM DB op te vragen......

 

Met de context van Filemaker bedoel ik de tabloccurrence waarop de layout is gebaseerd waar je op een gegeven moment bent en daarmee alle met die TOC verbonden TOC's. De scope van de data die je kan gebruiken in formules en scripts is gehouden aan die context. Met ExecuteSQL() kan je data opvragen die je normaal met je voorhanden schema niet zou kunnen opvragen.

 

Je hebt bijvoorbeeld bedrijven, met daarbij in een aparte tabel de personen bij die bedrijven. Nu kan je bij een bedrijf uit een portal alle personen opvragen met bijvoorbeeld:

List ( Personen::VolledigeNaam )

omdat je die tabel met een relatie hebt gekoppeld aan bedrijven. Wil je echter alleen de personen van het vrouwelijke geslacht hebben, dan zou dat met een extra relatie moeten doen. Met ExecuteSQL is dat niet nodig want dan kan je gewoon een query bouwen die dat doet en die zou er dan zo uit kunnen zien:

ExecuteSQL("SELECT VolledigeNaam FROM Personen WHERE IDBedrijf=? AND Geslacht=?"; "" ; ¶ ; Bedrijf::ID ; "V" )

Het voorbeeld is wat simpel, maar met ExecuteSQL kan je vaak toe met heel wat minder relaties .... je toont tenslotte lang niet alle gegevens in portalen.

[Felix]

.

3 oktober 2015 aangepast door Gast

[menno]

De scriptstap "Execute SQL" is iets anders dan de calculatie ExecuteSQL(). De laatste is waar ik het over had.

 

De sriptstap waar jij mee bezig bent is echter ook niet zo heel lastig:

Je hebt een DSN (Data Source Name) nodig. Dat is een bestandje wat de verwijzingen naar de odbc-driver en een odbc-begrijpende-database bevat. Je kan koppelen met met MySQL, Oracle, Sybase etc.etc. door een SQL-query via die DSN te versturen. Je krijgt dan als antwoord een komma-gescheiden tabel terug die je als tekst verder kunt verwerken, of nog handiger direct (via odbc import) kunt importeren.

 

Om een DSN te maken heb je ten eerste ODBC-drivers nodig én een tool om DSN's te maken. Nu ben ik even inbetween mac's omdat ik mijn macbook air heb verkocht en mijn macbook pro is nog niet geleverd, dus ik kan je nu geen schermen tonen hoe je dat instelt. Je kan echter bij apple een tool downloaden om de DNS's in te stellen: http://support.apple.com/downloads/ODBC_Administrator_Tool_for_Mac_OS_X

Je hebt dan echter nog geen drivers, die zijn voor MacOSX meestal lastig te vinden (dwz gratis is lastig), maar je kan ze ook gewoon kopen bij http://www.actualtech.com/

 

Een andere mogelijkheid is met je mac in een omgeving met een op Windows draaiende FMServer te werken. De driver voor windows zijn bijna altijd gratis en er is ook al een odbc-control-panel in het os aanwezig. Als je dan eerst een DSN aanmaakt op die server (zorg dat je een system-dsn) aanmaakt, dan kan je die op alle machine's (inclusief Mac's) die op die FMServer bestanden open hebben, gebruiken. Ik zal in de loop van de week wel even kijken of ik een voorbeeldje met screenshots in elkaar kan flanzen, dan zie je hoe het er uitziet.

[Felix]

.

3 oktober 2015 aangepast door Gast

[menno]

No problem, dan weet je dat nu ook weer, 't Is echt een heel handige functie. Ik maak er kwistig gebruik van. Ik deed dat in FM11 al met de plug-in myFmButler (die gebruik ik overigens nog steeds), maar voor de "SELECT" gebruik ik zoveel mogelijk de ExecuteSQL(). De overige basisqueries (INSERT, UPDATE en DELETE) kunnen niet met de ExecuteSQL-functie en structuur-queries (CREATE, DROP en TRUNCATE), die overigens ook niet kunnen met ExecuteSQL(), gebruik ik nooit in FM.

 

Als je goede informatie en voorbeelden zoekt kan jet terecht op de volgende pagina's:

http://www.filemakerhacks.com/?p=6406 en http://www.filemakerhacks.com/wp-content/uploads/2012/10/The-Missing-FM-12-ExecuteSQL-Reference.pdf

Zowel het artikel als de pdf zijn gemaakt door Beverly Voth en zeer informatief. Onderaan het artikel staan links naar voorbeeldbestanden en naar nog meer informatie.

 

Ik zal over de scriptstap Execute SQL binnenkort wel een paar screenshotjes en uitleg plaatsen in de tips en tricks sectie, maar eerst als ik wat meer tijd (en zin) heb. Je kan namelijk al eeuwig lang via odbc-import data in filemaker importeren. Als je data in je schema wilt opnemen die niet in het rijtje Oracle9,10, 11, MsSQL2000-2008, MySQL4/5 staat, dan is odbc-import een onmisbaar alternatief. Okay je kan dan wel geen data terugsturen, maar vaak is kunnen lezen al genoeg.