Ga naar inhoud

menno

Moderators
  • Items

    2.185
  • Registratiedatum

Alles dat geplaatst werd door menno

  1. Hoi W, Je script zal oneindig doorlopen, want je hebt geen exitvoorwaaarde gesteld (met de stap: exit loop if[]). De stap open record heeft ook geen nuttige functie want dat doe je nu nadat je een waarde op het record hebt gewijzigd en dan is het record geopend en hoef je het niet nog eens te openen. Maw zet eerst eens op een rijtje wat je wilt en probeer dat te vertalen naar handelingen die Filemaker voor je gaat uitvoeren dmv een script. Als je je wensenlijst hier post, dan kunne we je helpen met het vertalen naar filemaker Mvg, Menno
  2. In het topic over de invoer van de decimaalpunt/komma werd bij één van de oplossingen een scripttrigger gebruikt en onstond er wat discussie of de wijze waarop sommige van de scripttriggers zijn geïmplementeerd. Nu zal FMI niet zomaar de werking achteraf gaan aanpassen en ons daarmee met nieuwe problemen opzadelen, dus keuzes die eenmaal zijn gemaakt, zullen niet snel worden aangepast. Scripttriggers kunnen behoorlijk tricky zijn en kunnen elkaar soms ook beïnvloeden. Verder geldt er ook voor de scripttriggers een soort van "meneer-van-dale-wacht-op-antwoord" achtige regel die de vaste volgorde bepaalt wanneer je scripttriggers met elkaar combineert zoals in berekeningen met optellen, delen en machtsverheffen er in. Wim Decorte heeft dat op een mooie inzichtelijke manier uitgelegd in een artikel op de Filemaker-Hacks website. Je kan daar ook een pdf met uitleg en een voorbeeld bestand downloaden.
  3. Heb je hier: http://www.geistinteractive.com/godraw/overview/ al naar gekeken? Of is dat niet wat je bedoeld?
  4. Toch ben ik dat niet met je eens: De kenmerken van het veld (in afloop 2 wel te verstaan) zijn dat on entry de volledige veldinhoud moet worden geselecteerd en de combinatie met de scripttrigger zorgt voor dit gedrag .... vul voor de grap nu een een "punt" in dat veld in ..... dan zal je zien dat eerst de scripttrigger wordt uitgevoerd, want de "punt" blijft gewoon in het veld staan en ook als je met de muis ergens in de layout buiten een veld klikt en daarmee het record vastlegt, dan blijft die "punt" nog steeds staan en wordt dan niet vervangen door een komma Eerst wordt de trigger uitgevoerd (aan het begin van de keystroke) en dan wordt de keystroke zelf uitgevoerd Ik ben met je eens dat je dit gedrag niet direct zou moeten hoeven verwachten, maar het is navolgbaar en vooral consistent, dus ik mag hopen dat ze dit niet meer veranderen (wijziging heeft altijd gevolgen voor software die daarvoor hebt gemaakt)
  5. Ik ben er niet van overtuigd dat dit een bug van filemaker is. Script-triggers kunnen gewoon heel tricky zijn, omdat de definitie letterlijk is te nemen. Doe je dat niet, dan wordt het inderdaad onvoorspelbaar. ik wil dat graag even aan de hand van de hier gebruikte "OnKeyStroke"-trigger illustreren: De OnKeyStroke-trigger wordt getriggerd door een willekeurige toetsaanslag. Willekeurig is letterlijk te nemen want of je nu een karakter-, cijfer- of navigatie-toets gebruikt, levert allemaal hetzelfde resultaat: Het toegewezen script wordt uitgevoerd en vervolgens wordt de toetsaanslag verder verwerkt. Er zijn twee mogelijke aflopen en dat is afhankelijk van de instelling "Select entire contents on entry" Basissituatie voor beide aflopen: Stel het getal 55 is ingevoerd in het veld en je plaatst de cursor in dat veld, Afloop 1 ("Select entire contents on entry"=UIT) dan wordt de cursor aan het einde van de reeds ingevulde waarde geplaatst. Geef je nu één toetsaanslag, dan wordt direct het script getriggerd en de waarde die nu nog ongewijzigd is aangepast en daarná wordt de toetsaanslag uitgevoerd .... vulde je daar nu een punt "." in, dan staat daar dus: 55. Ga je nu met tab of enter naar het volgende veld of leg je record vast, dan is dat weer een keystroke en wordt de inhoud van het veld via de het getriggerde script aangepast tot: 55, (Leg je het record echter vast door met de muis buiten alle velden ergens op de layout te klikken, dan blijft de inhoud staan en wordt dus de punt niet vervangen, omdat je het script niet triggert) Afloop 2 ("Select entire contents on entry"=AAN) de gehele veldinhoud geselecteerd. Geef je nu één toetsaanslag waarmee je de waarde van het veld zou wijzigen, dan wordt achtereenvolgens, het script getriggerd, de veldinhoud aangepast, het veld opnieuw geselecteerd (want dat is de standaard beginsituatie bij het binnengaan van het veld) en de toetsaanslag wordt uitgevoerd (na een toetsaanslag is de veldinhoud nooit geselecteerd, maar blijft de cursor staan waar de laatst actie plaatsvond). Het gevolg van deze afloopwijze is dat bij een wijzigende toetsaanslag altijd de gehele veldinhoud wordt vervangen, terwijl een tab, een enter (zonder wagenterugloop) of een pijltoets de inhoud laat staan of aan het begin of einde van het veld de cursor laat knipperen. Je kan het gedrag van de trigger in combinatie met de stel-veld scripstap heel gemakkelijk controleren door een pause-/resume-script direct na de stel-veld-stap te plaatsen en dan zie je (met de debugger aan) meteen wat er gebeurt. Ik vind het gedrag dus wel verklaarbaar en kan het geen slodigheid noemen, maar ik ben het wel met je eens dat het niet zo heel erg voor de hand ligt. Er kan hier over scripttriggers wel een eigen rubriek op worden gezet, zo complex als dat onderwerp is. Het lastige bij scripttriggers is de timing, je moet precies bewust weten wanneer de triggers hun werk doen.
  6. Het probleem is dat op de bedrukking van de toetsen een punt is afgedrukt op het numerieke toetsenbord. Filemaker gaat daar niet raar mee om, want het Operating System geeft een punt aan Filemaker door en omdat dat ook op de toets staat is dat in principe ook correct. Word, notepad, eclipse, photoshop etc. etc. zullen allemaal een punt tonen, behalve excel, daarmee hebben ze bij MS ineens gedacht: "die punt daar is onhandig, natuurlijk willen mensen daar het decimaal-teken gebruiken, laten daar naar de landinstellingen kijken en het juiste teken doorgeven" Gelukkig hebben ze bij Apple nooit zo moeilijk gedaan over die punt op het numerieke toetsenbord, afhankelijk van je land-instellingen wordt daar al sinds jaar en dag de komma of de punt op de juiste wijze doorgegeven. Dus Filemaker doet het niet fout, maar Windows doet het fout Is de trigger die je gebruikt toevallig "onkeystroke"? In dat geval zal iedere toetsaanslag het scriptje triggeren en dan wordt je gek, je kan ook "onfieldexit" gebruiken, dan wordt ie maar een keer getriggerd, dan zal het mogelijk beter gaan. Ik ga het ff testen ..... [edit]Ik heb het inmiddels even getest .. bij mij gaat de "onkeystroke" ook niet goed als "select entire field contents on entry" aanstaat. De "onfieldexit" werkt wel prima blijkt en wordt getriggerd bij het verlaten van het veld, maar nog vóór het werkelijke verlaten en dan gaat het gewoon goed. [/edit]
  7. Met een standaard patterncount kijk je of of de waarde rechts voorkomt in de waarde links. Dus: Patterncount ( "117" ; "7" ) = Patterncount ( "117" ; "1" ) = Patterncount ( "117" ; "17" ) = Patterncount ( "117" ; "11" ) = Patterncount ( "117" ; "117" ) ik denk dat je gewoon moet kijken naar of het recordid gelijk is aan degene die je hebt geselecteerd. Als dat een stapel van id's is kan je dat ook bijvoorbeeld aanvullen met returns: Patterncount ( ¶ & "117" & ¶ ; ¶ & id & ¶ ) en dan lukt het denk ik wel mvg, Menno
  8. Eigenlijk ben je hiermee bezig van een systeembeheerprobleem, dat ook nog eens alleen op Windows een probleem is, jouw probleem te maken . Ik heb daarom eens even gezocht op internet en heb daar de volgende site gevonden: http://webpages.charter.net/krumsick/ Je vindt daar "KeyTweak.exe" keurig met een handleiding hoe je het moet doen (je kan ook het onderstaande plaatje als voorbeeld gebruiken en daarna hertstarten). Als je de layout wijzigt, dan geldt die wijziging voor alle gebruikers die van die machine gebruik maken, dus op een terminal server hoef je dit maar één keer te doen .... Anyway op deze manier hoef je geen slimme velden meer te maken en werkt de komma met de decimale punt invoeren in alle velden, net als op de mac mvg, Menno
  9. De meeste mensen hier op het forum hebben toch wel een voorkeur voor MacOS om op te werken en zijn dan ook iets minder thuis op een windows-server. Als je op een Window Server 2008 Standard of webedition een FMS-installatie doet dan blijft de Firewall vaak dicht staan. Die kan je als volgt aanpassen: Zodra je inlogt op de server opent meestal automatisch "Serverbeheer". Kies daarin voor "Configuratie" en daarin voor "windows firewall ...". Dan klik je op "Regels voor binnenkomende verbindingen" en klik daar op "Nieuwe regel..". Dan wordt een een wizard gestart: Selecteer "Poort" en klik op "volgende" Selecteer "TCP" en "Specifieke locale" en vul de volgende waarden in: voor alleen FMS 12: 5003, 5013, 5015, 16000, 16001, 16004, 50003 voor alleen FMS 11: 5003, 5013, 5353, 16000, 16001, 16004, 50003 voor alleen FMS 10/9 etc: 5003, 5353, 16000, 16001, 16004, 50003, 50006 Gebruik je ODBC/JDBC voeg dan de ODBC-poort toe: voor alle FMSA versies: 2399 Als je vanaf de FMS ook nog mail verstuurt en ontvangt dan moet je de volgende poorten (afhankelijk van je gebruikte protocollen) openzetten: smtp: 25 (SSL: 465) pop: 110 (SSL: 995) imap: 143 (SSL: 993) Gebruik je ook CWP/IWP dan mag je nog een paar extra poorten toevoegen: voor FMS 12/11/10/9: 80, 16006, 16008, 16010, 16012, 16014, 16016, 16018, 16020, 16021 Heb je een losse webserver dan moeten daarop een apart lijstje met poorten worden geopend: voor alle FMS versies: 80, 16000, 16004, 16006, 16008, 16010, 16012, 16014, 16016, 16018, 16020, 16021 NB: bij de webservers kan je ipv poort 80 ook een alternatief gebruiken zoals 443, 591 of 8080 Als je maar alle waarden van elkaar afscheidt met een gewone komma (,) en klik op "volgende" Selecteer "De verbinding toestaan" en klik op "volgende" Selecteer één of meerdere van de profielen "Domein" , "Privé" en/of "Openbaar" en klik op "volgende" Vul een naam in (bijvoorbeeld "Filemaker Server inkomende poorten") en eventueel (is wel handig om het wel te doen) een beschrijving en klik op "voltooien" Als het goed is is er voor "Bonjour" al wel een goed werkende entry. Controleer daar even bij welke profielen "Domein" , "Privé" en/of "Openbaar" de firewall wordt geopend, dat moeten dezelfde zijn als voor Filemaker Server. mvg, Menno kijk voor de details over de benodigde poorten ook even op: http://help.filemaker.com/app/answers/detail/a_id/6427/ en voor FMS12 op: http://help.filemaker.com/app/answers/detail/a_id/10672/
  10. Zoeken in de inhoud: het zou handig zijn als je de tekst van een document zou kunnen doorzoeken, of tenminste de metainformatie. Nu moet je dat zelf opgeven in een veld naar keuze met een procedure naar keuze. Filemaker biedt zelf helemaal geen mogelijkheden (al was het maar voor .doc(x) .xls(x) .odf .odt en alle tekstgebaseerde bestandsformaten)
  11. Wat heeft de klant verder in zijn netwerk draaien en heeft hij een systeem beheerder? Als de overgrote meerderheid van de gebruikers bij jouw klant MacOSX draait, dan zou ik inderdaad een Mac-Mini adviseren (mits niet teveel gebruikers, anders misschien beter een Mac Pro). Werken ze echter hoofdzakelijk op windows, dan zou ik toch een Windows Server 2008 of 2011 Standard-Edition laten aanschaffen (2003 is wel een beetje verouderd en ook niet de SBS-versie ivm conflicten met sharepoint- en exchange-server). Het enige wat je bij Win2008/2011 moet weten is dat bij de installatie de firewall niet automatisch wordt aangepast... en dat is simpel op te lossen. Als je wilt kan ik je die info sturen of hier op het forum posten bij de tips en tricks ofzo.
  12. Hoi Patrick, mijn eerste vraag is: gebruik je Filemaker Pro 12 advanced? Zo ja, dan kan je de onderstaande plaatjes gebruiken als handleiding
  13. [edited 2012-07-14 16:25 /]
  14. Op http://www.filemaker.com/ce/products/fms/tech_specs.html staat bij capacities bij IWP dat het maximum 100 gebruikers is en dat is bij alle versies sinds 7. De enige versies waar die beperking niet gold was filemaker 5/5.5/6 unlimited, maar dat was een speciale client-versie voor webpublishing en geen filemaker server versie. Je kan met fmserver overigens wel 200 cwp-clients bedienen. Een manier om deze maxima te omzeilen is er niet.
  15. Als je dat niet wilt, houdt dat dan in dat alle gebruikers met de account "Admin" met "[full privileges]" gebruik maken van jouw bestand? In dat geval valt er niets te beveiligen, je zou op de layouts wel alle velden op "niet toegankelijk in blader" kunnen zetten, maar de menucommando's "nieuw", "dupliceer", "verwijder" en "verwijder alles" blijven gewoon beschikbaar. Wil jij dat mensen de data niet kunnen wijzigen, dan zal je denk ik ook niet willen dat ze zomaar records toevoegen of verwijderen. Ik zou in jouw positie toch het gebruik van accounts en privileges overwegen. Mensen die alles mogen en op PC's en Mac's gebruik maken van de bestanden kan je gebruik laten maken van de admin-account en iPad/iPod gebruikers van bijvoorbeeld de guest-account. Je kan dat heel simpel opzetten, door 1) eerst de guest-account te activeren (standaard is ie uit) en zorg in de extended-privileges dat fmapp-privilege voor de guest-account aanstaat. 2) een startscript te maken waarin ergens tijdens het openen controleert met welk platform de gebruiker het bestand opent: if ( Abs ( Get ( SystemPlatform ) ) < 3 and Get ( CurrentPrivilegeSetName ) ≠ "[full access]" opnieuw aanmelden [ account name:"admin" ; no dialog ] end if 3) bij de BestandsOpties geef je aan dat automatisch wordt ingelogd met de "guest-account" ipv de "admin-account" die nu staat aangevinkt. In diezelfde dialoog geef je op de tab Scriptactiveringen aan dat het script uit stap-2 hierboven bij het EersteVensterOpenen moet worden afgedraaid. Als nu het bestand opstart, zal iedereen vanzelf de guest-account gebruiken om het bestand te openen. Iedereen die geen gebruik maakt van een iPad/Pod zal door het startscript automatisch worden ingelogd via het admin account, zonder dat ze daar zelf iets voor moeten invoeren. Zo is het de bedoeling toch? succes , Menno
  16. menno

    BigInputDialog van Troi

    Hoi D, de dialogplugin kent de volgende basisdialogen: flash (flitsdialoog zonder knoppen) progress/barberpole (voortgangsinidicator) standard (standaard met maximaal 4 knoppen) input (invoerdialoog met maximaal 15 velden/checkboxen en maximaal 4 knoppen) biginput (invoerveld met 1 groot invoerveld en maximaal 4 knoppen) Deze dialogen zijn niet met elkaar te combineren, alhoewel de rest van de toolset van de plugin in meer of mindere mate wel wordt gedeeld door de functies. Jij stelt je denk ik een dialoog voor waar je bijvoorbeeld een aantal velden met een groot tekstvlak wilt combineren en dat gaat helaas niet. Je kan even kijken of deze http://www.dracoventions.com/products/2empowerFM/family/dialog.php plugin je meer mogelijkheden geeft, er staat daar een voorbeeldje dat precies dat doet wat jij wilt mvg, Menno
  17. In het voorbeeld is het venster leeg, form-view, geen velden en 1 record gevonden. De gebruiker ziet wel dat ie niets op de layout kan en mag doen.... ik vind het dus minder een probleem dan jij, maar ieder zijn eigen mening en kritiek geven mag natuurlijk altijd Filemaker 12 biedt wat meer mogelijkheden, doordat je van een venster alle knoppen kan uitschakelen, kan je in combinatie met een andere scripttrigger het een en ander op een wat elegantere manier oplossen.
  18. Je kan in een tekstveld geloof in 1Gb tekst kwijt, in een variabele kan je meen ik ook 1Gb kwijt (in een variabele in de dataviewer kan je tot 30000 tekens plakken, maar wel 1Gb uit kopiëren). Voor plugins zelf intern zal die beperking niet gelden, maar voor de resultaten die een plugin doorgeeft aan FM zal die "beperking" waarschijnlijk ook gelden verwacht ik.
  19. Als je de structuur van je database gaat aanpassen, dan kan dat alleen wanneer alle door jou geopende records worden gecommit. Aangezien de scripttrigger op de login-layout aan een commit op die layout hangt en het getriggerde script de applicatie afsluit als de variabele $$noexit niet is ingesteld, zal filemaker dus afsluiten (zie de beschrijving). Hetzelfde zal dus gebeuren als je de definties van de user-tabel (niet van de data-tabel) hebt gewijzigd en wilt vastleggen, dat gaat pas lukken als alle gebruikers die iets wijzigen in die tabel (en dat zijn bij dit bestand alle gebruikers) hun open record(s) committen en dus bijgevolg van het getriggerde script filemaker afsluiten. Voor jezelf kan je het afsluiten voorkomen door eerst de variabele $$noexit te vullen met een 1: set-variable[ $$noexit ; not ( $$noexit ) ] Na het wijzigen het startscript weer even draaien, of nog beter even het hele bestand afluiten en opstarten. Dat de gebruikers het door jou wijzigen van de definities kunnen verhinderen, zolang ze hun record(s) niet committen is wel een beetje lastig, maar denk maar eens terug aan FM5/6 waar gebruikers het bestand moesten sluiten vóórdat je de velddefinties inging of nog erger FM2/3/4 waar je de bestanden van de server moest halen om de velddefinities aan te kunnen passen. Dan valt het eigenlijk wel weer mee, maar daarme dwalen we af van het punt van deze draad
  20. Hoi Felix, ik heb een bestandje bijgvoegd met de techniek uitgewerkt: 1) Bij het opstarten moet de gebruiker opgeven wie hij is (dat kan ook anders, maar in het kader van de demo even op deze manier) 2) Bestaat de gebruiker nog niet dan wordt hij aangemaakt(ook dat kan anders, maar dit is ook weer in het kader van de demo) 3) Is de gebruikers al ingelogd, dan moet hij anders inloggen of annuleren, of als hij heeft afgebroken en de server denk dat hij nog is ingelogd ... even wachten tot de server het record weer vrijgeeft. 4) Na het inloggen wordt het inlogscherm verborgen en gaat de gebruiker zijn ding doen Nu kan je op ieder gewenst moment met een scriptje de actuele gebruikerslijst uitvragen. Er is een kleine kans dat 2 gebruikers exact tegelijk de lijst uitvragen, maar die acht ik voor het gemak even verwaarloosbaar. Haalt de gebruiker nu het verborgen scherm naar voren, dan heeft hij 3 mogelijkheden: 1) Venster sluiten 2) De knop (ligt over de gehele layout) indrukken 3) Met een enter het record vastleggen in alle 3 de gevallen wordt het record gecommit en zal de scripttrigger om af te sluiten worden geactiveerd Er kan vast nog het een en ander worden verbeterd, maar dit is in grote lijnen wat ik in gedachten had Veel plezier en ben benieuwd naar jullie oplossing(en) groeten, Menno Users_ingelogd.fp7
  21. Er worden verschillende manieren gebruikt door ontwikkelaars om gebruikers in te laten loggen en hun privileges te bepalen. Het handigste om überhaupt te bepalen wie er zijn ingelogd is het aanleggen van een tabel met alle gebruikers. Of die tabel een afspiegeling is van de gebruikerslijst uit "account and privileges" of dat het een kompleet eigen lijstje met users is dat maakt voor de onderstaande techniek niet uit, als je maar voor iedere gebruiker een eigen uniek record hebt... Een gebruiker logt in in het systeem en opent zijn persoonlijke record, maakt daar een nieuw venster en blokkeert vervolgens het actieve record met bijvoorbeeld: Set Field [ Users::Function ; Users::Function ] het gaat er hierbij om dat een willekeurig veld wordt gesteld met de waarde van zichzelf, zodat je niets wijzigt. Vervolgens verberg je het venster weer, waardoor voor de gebruiker zelf de functie: get ( RecordOpenState ) een 2 zou opleveren. Zolang de gebruiker de toepassing niet sluit, laat crashen en ook het record niet "commit" of "vastlegt" kan niemand anders dat record wijzigen ..... Nu als een andere gebruiker ook is ingelogd en die gaat dan controleren wie er allemaal is ingelogd, dan hoef je alleen maar een lusje langs alle user-records te lopen waar je gedurende die lus op iedere record een veld probeert te stellen. Als je foutafvanging aan hebt staan, dan levert dat bij een door een andere user "bezet" record een fout (nr 301) op. In dat geval vul je een variabele aan met de gebruikersnaam en zo weet je aan het einde van de lus wie er allemaal is ingelogd. . Die gevulde variabele kan je daarna gebruiken om een lijstje te tonen of iets anders naar eigen goeddunken te doen Laat iemand nu zijn filemaker crashen (zoals eerder opgemerkt), dan zal Filemaker Server die user na ca 2 minuten zelf loskoppelen en het record weer vrijgeven. De functie Get ( RecordOpenState ) werkt helaas alleen lokaal en dus kan je daarmee niet zien of iemand anders een record bezet houdt, je zal dus met Set Field moeten proberen een fout te veroozaken. Ik gebruik deze techniek zelf nog niet, maar heb hem net even in een proefomgeving getest en daar werkt het zowel op macos als windows
  22. Je kan steekdatum vervangen voor Date ( 9 ; 30 ; year ( get ( currentdate ) ) ) mvg, Menno
  23. Een laptop, desktop of minitower (LDM) is nooit bedoeld voor 24/7 gebruik omdat ze qua levensduur berekend zijn op ca 60 uur gebruik per week. In een server worden per definitie componenten gebruikt die er op zijn berekend om na aanschaf ca 5 jaar onafgebroken te functioneren, bij LDM's wordt er rekening gehouden met intermitterend gebruik in dezelfde periode. Dat wil niet zeggen dat ze niet zolang mee kunnen gaan, maar dat ze niet voor dat gebruik worden gegarandeerd. Verder is er een verschil in de manier waarop het OS van een LDM (in de standaard instellingen) reageert tov een server. Sommige bezwaren liggen helemaal niet zo voor de hand, dat bedoel ik met niet voor 24/7 mvg, Menno
  24. Hoi HE, ik begrijp je gedachte met betrekking tot de stroomvoorziening en de snelheid van de ssd, maar dat is niet de enige eis die je aan een server zou moeten stellen. Bovendien is een MBA op de batterij waarschijnlijk een flink stuk trager dan aan de adapter en eigenlijk is ie ook niet gemaakt om 24/7 te draaien. Een server is verder server en geen werkstation, dus een scherm heb je niet nodig en een toetsenbord eigenlijk ook niet, want met rdp/vnc kan je het ding op afstand onderhouden ... een MBA is ook voor een kleine werkgroep nog steeds relatief duur. Een kleine UPS om een mini aan de gang te houden hoeft denk ik niet meer te kosten dan een paar honderd euro en lijkt mij een beter alternatief (voor een kleine werkgroep dan). Maar smaken en meningen verschillen nou eenmaal, dus je hoeft het natuurlijk niet met me eens te zijn groeten, Menno
  25. Hallo Allen, even een update: het probleem is opgelost. Op https://fmdev.filemaker.com/message/85153#85153 heeft Steve_ssh me aan de oplossing geholpen. Voor diegenen die de link niet kunnen/mogen/willen/etc. volgen komt de oplossing in een notedop op het volgende neer: In het geval dat het bestand op iPad wordt gebruikt moet de link in de DIV's ipv een anker een FMP-link zijn en de scripttrigger op de webviewer moet in het geval van iPad worden gekilld. Verder zijn er nog wat kleine tweeks, maar dit is de essentie. Ik had ook al met het FMP-protocol zitten proberen, maar was zelf niet op het idee gekomen de scripttrigger te killen .. dankzij steve is dat nu opgelost. Ik ben nog lang niet klaar met deze oplossing: css- en html-code optimaliseren, bedienen dmv het lezen van streepjescodes, decentrale dataopslag en synchronisatie moeten nog worden toegevoegd, maar dat levert geen problemen meer op Ter verduidelijking heb ik het bestand dat steve heeft aangepast bijgevoegd, zodat jullie (indien geïnteresseerd) ook je voordeel mee kunnen doen ;D mvg, Menno
×
×
  • Nieuwe aanmaken...