Banach

Kun je daar dan niet de graphic zelf als knop definiëren?

Dank voor je reactie. Klopt het dat jouw oplossing alleen vanaf de server zelf gaat werken? Vandaag weer ergens anders gezien dat het vanaf de server zelf redelijk goed werkt maar bijzonder traag vanaf een andere machine in hetzelfde netwerk/ Deze keer nota bene met FMS 14v2. Je zou haast denken dat er nog een extra poortje open moet staan, danwel dat 1 van de poorten naast TCP ook UDP moet doorlaten. Ik weet het niet hoor maar het lijkt dus simpelweg een verbindingsprobleem.

Bij twee verschillende servers hetzelfde probleem: FMS 13, admin console. Openen en dan zie je de statuspagina. Klik je op een functie in de navigatiebalk aan de linkerkant, b.v. voor clients. dan verschijnt rechts een rood tandwieltje dat overigens niet beweegt en gebeurt er verder helemaal niets meer. Alleen door af te breken en opnieuw kontakt te maken kun je weer de statuspagina oproepen. Herkent iemand dit? Oh ja, Windows server 2012.

Men zou ook Single Sign On moeten ondersteunen om enigszins als volwassen database te worden aangezien in many client omgevingen. In sommige situaties kan het ontbreken hiervan zelfs een dealbreaker zijn is mijn ervaring. Daarnaast zou in dit verband een gedetailleerd rapport van de aangebrachte wijzigingen en gedrag ook wel op zijn plaats zijn. Het ontbreken van een goede changelog komt niet erg professioneel over en geeft weinig vertrouwen of ondermijnt dat zelfs. Ik wil als ontwikkelaar niet een deel van mijn tijd testpiloot voor FileMaker, Inc. zijn.

Een map openen gaat via het file protocol met de script stap Open URL. Zie: http://www.filemaker.com/help/12/fmp/nl/html/scripts_ref2.37.65.html#136127 Bijvoorbeeld de map Dossiers openen die op je bureaublad staat doe je met: Open URL ["file:///users/je-gebruikersnaam/desktop/dossiers"] Let op de 3 (!) slashes vooraf. Hoe je zo'n link dmv slepen in FM zou kunnen krijgen weet ik niet.

Ik zie geen problemen, het werkt.

Primair gebruikt FM de opmaak waarmee de tekst door de gebruiker is ingevoerd. Secundair het type waarmee het veld in layout modus is gedefinieerd. Bij knippen/plakken van tekst wordt de opmaak van het knipsel gebruikt. Wellicht is dat hier de oorzaak. Je kunt de gebruikers opmaak verwijderen door eerst de tekst te kopiëren (ctrl-c c.q. cmd-c of knippen, ctrl-x, cmd-x) en dan te plakken (ctrl-v, cmd-v) en vervolgens de stijl te verwijderen dmv ctrl-z, cmd-z. Of gebruik de menuoptie 'plakken zonder stijl'.

Dat is een heel goede suggestie. Probleem is alleen dat er geen gebruikerstabel is. De bestanden zijn volkomen onbeveiligd en het zijn er ook nogal wat. Het geheel stamt nog uit de pré FM 7 tijd. Het is mij iets teveel werk om dat nu goed te organiseren (liefdewerk, oud papier, je kent het wel )

Het verzenden via SMTP is inderdaad een optie. Probleem is wel dat deze mails verstuurd worden vanaf verschillende clients en dat het adres voor de bcc dus varieert. Een bcc naar een vast adres zou deze complicatie oplossen. Ik ga dit de gebruikers voorleggen. Bedankt voor de suggestie.

Ja dat denk ik wel. Tellen hoeveel klanten je hebt kan eenvoudigweg door de 'klant' records te zoeken en dan het aantal gevonden records te tonen. Dat kun je zelfs middels een script doen. En zelfs dynamisch middels een relatie met het relatiebestand zelf (self-join). Je koppelt dan aan alleen de klantrecords en gebruikt de functie count() in een berekening.

Dat geldt ook voor FMServer, die mag je dan ook niet uitzetten. Je kunt een kopie van de DB op je iPad zetten, maar dan moet je wel iets maken om de wijzigingen te synchroniseren met de op dat moment niet gebruikte versie op je computer. Dat is nog niet zo eenvoudig. Veel gemakkelijker is het dan om de hele database steeds heen en weer te zetten bijvoorbeeld door deze in de cloud te zetten en naar beneden te halen wanneer je op computer of iPad gaat werken. Ben je klaar, dan zet je het weer terug in de cloud.

Geen antwoord op je vraag, maar waarom zou je klantnummers opeenvolgend willen hebben?

Beiden zeer bedankt voor jullie inbreng. Voor mij geldt eigenlijk dezelfde insteek als welke Menno hier beschrijft. Ook maak ik layouts welke alleen bereikbaar zijn voor bepaalde gebruikers waarop enkele velden dan wel writable zijn. Daarmee kunnen beheerders e.d. reeksen van records aanpassen terwijl ze die records ook in beeld hebben. De mogelijkheden om records toe te voegen en/of nieuwe velden aan te maken kun je afschermen m.b.v. de privilegesets voor de verschillende gebruikers. Gelukkig maar want anders zou het inderdaad een volkomen onbruikbare weergave modus zijn. Het idee om een heel smal (leeg) veldje als eerste veld toe te voegen is helemaal geweldig. Ik heb zo'n veldje (een global) helemaal vooraan gezet en handmatig op een breedte van 1 pixel gezet. Je ziet het dan niet en ook het verschuiven van de barcode kolom naar een positie vóór deze lege kolom gaat nog niet zo gemakkelijk (mij lukt het niet), daarmee blijft die lege kolom vrijwel altijd het eerste veldje. En inderdaad, de opmaak van dit dummy veldje op de layout bepaalt nu helemaal de opmaak van de kolomlabels, lettertype, grootte, vet, onderstreept, cursief enz het werk allemaal door in de kolomlabels. Kleur van de letters en achtergrond echter niet. Ook nul px geprobeerd, maar dat heeft geen effect. Erger nog je krijgt het kolommetje niet meer geactiveerd en dus niet breder en dat kan je pas weer oplossen door het veldje eerst van de layout af te halen, de layout op te slaan en dan het veldje weer toe te voegen. Zet het kolommetje dus op 1 px breed. Dat gaat niet via het verschuiven van de rechter kolomgrens, dan kun je tot minimaal 20 px komen. Gebruik de optie Zet Kolombreedte onder het driehoekje in het kolomlabel. Opgelost dus

Vele malen snel achter elkaar refreshen blijft een goed resultaat geven.

Ok, nu geen enkel probleem:

Nou, voorlopig krijg ik er helemaal niks uit. Het bestand containerbridge zelf zit er ook niet bij.

Prima, stuur maar op.

Ik heb dat onder diverse installaties (fm10 t/m 14) draaien op zowel windows als mac. (10.8 t/m 10.10) Een heel andere benadering van de oorzaak van jouw probleem is om het in timing te zoeken. Wanneer een plaatje getoond moet worden kan dat al vervangen zijn door het volgende plaatje of juist nog niet beschikbaar zijn. Kijk eens of je met het tonen van slechts 1 en daarna 2, 3 enz een punt kunt aangegeven waarop het wel altijd goed of fout gaat.

Kijk eens wat een subresumé (subsummary) voor je kan doen. B.v. in de voetbal tabel: sorteer die op het teamnummer en maak een layout met een subresumé wanneer de records gesorteerd zijn op teamnummer. Plaats dat resumé gedeelte boven de body van het record en plaats in dat gedeelte het nummer van het team als veld of samenvoegtekst. In het recordgedeelte laat je de naam van de leerling zien. Een klein voorbeeldje van wat ik bedoel heb ik toegevoegd. voetbal.fmp12

Ik heb in de loop der tijden wat zitten rommelen aan de containerbridge en ga niet meer standaard uit van de extensie van het plaatje. Ik geef als het even kan het type van het bestand expliciet mee. Hier zit dat in de parameter -type. De parameter -file bevat expliciet de volledige filenaam van het plaatje. Dit is een apart berekeningsveld in mijn FM toepassing. De business-end voor het ophalen van de containerdata ziet er daardoor bij mij ietsje anders uit: if (isset($_GET['-url'])){ $url = $_GET['-url']; if (isset($_GET['-type'])) $type = $_GET['-type']; else $type = substr($url, strrpos($url, ".") + 1); if (isset($_GET['-file'])) $file = $_GET['-file']; else $file =''; if($type == "jpg"){ header('Content-type: image/jpeg'); header('Content-Disposition: inline; filename="'.$file.'"'); } else if($type == "gif"){ header('Content-type: image/gif'); header('Content-Disposition: inline; filename="'.$file.'"'); } else if($type == "pdf"){ header('Content-type: application/pdf'); header('Content-Disposition: inline; filename="'.$file.'"'); } else if($type == "tiff"){ header('Content-type: image/tiff'); header('Content-Disposition: attachment; filename="'.$file.'"'); } else { header('Content-type: application/octet-stream'); header('Content-Disposition: attachment; filename="'.$file.'"'); } echo $fm->getContainerData($url); } Maar eerlijk gezegd zie ik verder geen probleem in jouw versie.

Ik heb webpagina's draaien met tot wel 80 plaatjes. Die worden allemaal prima weergegeven. Een verschil met jouw situatie is dat dit gedaan wordt vanaf een layout in de tabel met de plaatjes, dus niet vanaf een gerelateerd record. Test eens of daar wellicht het probleem zit.

Ik loop tegen iets vreemds aan bij een lijst gegevens in tabelweergave. Het lettertype van de kolomlabels wordt kennelijk bepaald door het lettertype zoals dat in layoutmodus is aangegeven van het eerste veld dat in deze weergave getoond wordt. Dit is nogal lastig wanneer de lijst met een barcode begint. Zie de plaatjes: Met een gewoon veld beginnend: En met een barcode veld beginnend: Bug of feature? Ik weet het niet. Is dit op een of ander manier op te lossen? Of moet ik de gebruiker maar instrueren om het barcode-veld niet vooraan te plaatsen?

Ik zie dat je .psd plaatjes gebruikt maar in het containerbridge.php document worden alleen special cases uitgefilterd voor .jpg, .gif, .png en .pdf. Een psd krijgt dan altijd de header: Content-type: application/octet-stream Zou daar het probleem kunnen zitten. Je kunt dit testen door even alleen een stel .png (screenshots op de mac) plaatjes in de database op te slaan en op de webpagina op te roepen.

Wanneer je dit soort gegeven toch strikt gescheiden wilt houden kun je wel degelijk kiezen voor verschillende tabellen. Het overhevelen vanuit de ene tabel naar de andere gaat dan inderdaad het gemakkelijkste door de gegevens eerst middels een script te exporteren naar een tijdelijke Filemaker bestand en dan die gegevens in een andere tabel in te lezen. Als laatste actie moet je daarna de geëporteerde gegevens uit de eerste tabel verwijderen, maar pas nadat je zeker weet dat ze goed zijn overgenomen in de doeltabel.

Misschien is het ook interessant om even de inhoud van containerBridge.php hier te posten?