FilePath bewaren van import bestand

[Bonte]

Is er een mogelijkheid om de filepath van een extern bestand te weten komen nadat je iets het geïmporteerd daaruit. Het is de bedoeling een 2e import te doen op basis van gegevens uit die eerste.

 

De enige omweg die ik momenteel heb gevonden is alles importeren, controleren en van daaruit terug alles importeren in een ander bestand. Het liefst zou ik een klein gedeelte importeren om te controleren en dan met de filepath volledig opnemen maar ik weet niet of dit kan.

[mikezwet]

Misschien dat mijn post van vorige week even kan doornemen: http://www.clarify.net/viewtopic.php?t=2309

 

Ik stel met Get(Filepath) in waar een export bestandje moet worden opgeslagen.

 

Als je zo filepath opvraagt staat er ook file:// voor en bestandsnaam.fp7 achter, dat kan je weg filteren met de substitute functie. Ook kan je dan een extra map opgeven door er simpelweg & "mapnaam" achter te zetten, maar dat zie je in dat topic wel.

 

Ik exporteer automatisch door wat externe AutoIt scripts die ik oproep in een script van filemaker met "send event". Je moet je er even in verdiepten maar als je eenmaal de basics weet van AutoIt is het een leuk verlengstuk op FileMaker.

 

Wellicht kom je zo iets verder?

FilePath.fp7

[Bonte]

Ik heb de post gezien maar je kunt maar het pad opvragen van de huidige file, kun je dat ook te weten komen bij een externe file die je zopas geïmporteerd hebt? (Mac/Win)

 

De gebruiker moet met een venstertje de file aanduiden die hij wil importeren, het script importeert dan eerst een bepaald veld om te controleren welke acties het moet ondernemen en importeert dan de file in z'n geheel. Momenteel moet de gebruiker dus 2 keer de file aanduiden en dat zou ik graag vermijden.

[mikezwet]

Ik heb de post gezien maar je kunt maar het pad opvragen van de huidige file, kun je dat ook te weten komen bij een externe file die je zopas geïmporteerd hebt? (Mac/Win).

 

Het voorbeeld dat ik erbij heb gepost doet dat, als je een globaal veld ervan maakt staat dit path in elk record vermeld. Eventueel dus zonder bestandsnaam erachter.

 

De gebruiker moet met een venstertje de file aanduiden die hij wil importeren, het script importeert dan eerst een bepaald veld om te controleren welke acties het moet ondernemen en importeert dan de file in z'n geheel. Momenteel moet de gebruiker dus 2 keer de file aanduiden en dat zou ik graag vermijden.

 

Je heb dan dus het path in een veld staan maar als je dan een import opdracht geeft kan je het "importeer schermpje" niet laten verwijzen naar dat veld.

 

Wat ik dan doe: Ik maak een script die het path (met of zonder bestandsnaam erachter) kopieert en voer een event uit die een extern autoit script opent die een plakbewerking doet in het "importeer" scherm.

 

Omweggetje dus maar het werkt goed bij mij, storingsvrij is het niet want soms gaat het fm script sneller als het autoit script en dan loopt het vast.

[Bonte]

Het lukt me niet de file binnen te halen, hij is steeds beschadigd. Wil je hem nog eens gezipt posten?

[mikezwet]

Ok

FilePath.zip

[Bonte]

Bedankt, nu werkt het.

 

De voorwaarde is hier wel dat het in dezelfde map staat als de hoofdfile en dat kan ik niet garanderen, die kan overal staan.

[mikezwet]

Bedankt, nu werkt het.

 

De voorwaarde is hier wel dat het in dezelfde map staat als de hoofdfile en dat kan ik niet garanderen, die kan overal staan.

 

Je kan in de calculation een ander pad opgeven aan de hand van & "/mijnmap/submap"

 

Dan nog ben je gebonden, ik denk dat we teveel willen

[Bonte]

Het is een programma die verdeeld wordt dus heb ik geen extra info over plaats waar het staat. De enige oplossing die ik momenteel vind is alles importeren (desnoods op de verkeerde plaats), controleren wat er moet gebeuren en dan binnen de oplossing zelf nog eens importeren naar de juiste tabel.

[mikezwet]

Het is een programma die verdeeld wordt dus heb ik geen extra info over plaats waar het staat. De enige oplossing die ik momenteel vind is alles importeren (desnoods op de verkeerde plaats), controleren wat er moet gebeuren en dan binnen de oplossing zelf nog eens importeren naar de juiste tabel.

 

De plaats waar het programma staat kan je wel achterhalen Get(Filepath) en dan even de bestandsnaam eraf Substituten (Zie voorbeeld)

 

?

[Bonte]

Er zijn de updates met nieuwe boeken en die kunnen overal staan, de plaats van het programma kun je inderdaad achterhalen maar niet die updates.

[Rony Rabijns]

Gebruik dit eens om je containerveld uit te lezen. Misschien heb je er wat aan :

GetAsText(je_containerveld)

[Bonte]

Die kende ik nog niet, bedankt.

M'n probleem zal ik toch anders moeten oplossen, het is blijkbaar niet mogelijk de path te vinden van een bestand dat je importeert.

 

Wacht even, misschien is dit toch bruikbaar. Ik kan het bestand inlezen in een container (met referentie naar ...) en dan kan ik hiermee toch het path te weten komen om dan te importeren. Ik probeer het vandaag uit

[Bonte]

Gelukt, bedankt voor de oplossing. Ik krijg zelfs iets te veel info maar het path is er mooi uit te halen

 

Nu heb ik natuurlijk nog iets over het hoofd gezien, het is zo logisch dat ik ervan uitging dat je kunt importeren op basis van een globaal veld met die filepath. Niet dus ik vind geen methode om dat te doen. Nog ultieme tips?

[hbrendel]

Troi File Plugin

 

http://www.troi.com/software/fileplugin.html

[Bonte]

Duh, dat kost me 500 dollar. Niet handig voor dat ene programma die ik maak en wil verdelen met een runtime.

 

Je kunt in het script manueel het volledige pad intypen (zelfs meerdere) maar de inhoud van een globaal veld gebruiken kan dan weer niet. Belachelijk gewoon, heeft Filemaker een overeenkomst met Troy ofzo?

[Stef]

Dat is het erge punt van FM (vergeef me ...!).

 

Ik heb 2 dagen geleden net dezelfde opmerking gekregen van een klant die een klein beetje extra functionaliteit vroeg en daarvoor honderden euro's moet neertellen. Bovendien komt er nog bij dat deze klant voortdurend uitbreidt en er voor vanalles en nog wat bestellingen moeten geplaatst worden. Die plugins kosten op de lange duur meer dan FM zélf.

 

Ik blijf erbij: als die kleine plugin bedrijfjes dat zo makkelijk kunnen maken moet FM dat zélf ook kunnen met tientallen programmeurs! Het lijkt wel of ze niet meer durven en dat die bedrijfjes meer en meer macht krijgen.

 

Wij moeten als ontwikkelaars hier écht iets in de pap te brokken hebben!

 

MVG

Stef

[Bonte]

Die plugins werken soms wel lastig, zeker niets voor de gewone gebruiker dus dan begrijp ik het wel maar sommige zaken zijn zo logisch en makkelijk om toe te voegen dat het gewoon stom is of er zijn geheime afspraken. Ze kiezen maar

[Arnoud]

Wellicht een troost om te weten dat in Servoy de Menubar plugin ook is 'uitbesteed' aan derden...

 

m.vr.gr.

 

Arnoud

[Stef]

Arnoud,

 

Hier stuur ik niet op aan. 't Is toch wel erg dat ik bij de minste opmerking word opgedragen als een "overloper" naar Servoy.

 

Daarom:

 

-wij hebben nog een hoop klanten in FM en blijven daarom mateloos geïnteresseerd, in het belang van onze klanten

-het standpunt dat ik inneem over die ontbrekende functionaliteit stamt al van véél langer dan dat Servoy bestond (zoek maar op)

-denk nu niet dat ik dit forum blijf bezoeken om wat te "stoken", zo ben ik van nature écht niet, moest FM me volledig koud laten bleef ik hier wijselijk weg

 

En als je het dan toch over Servoy wilt hebben: het verdwijnen van de menubar bij Servoy is puur een gadget, je kan alles op een héél simpele manier opvangen (onload, onshow, ondatachange, onfind, ondelete, ondeleteall, onomit, onduplicate, onrecordchange, onrecordselection, onhide, ...), hetgene wat in FM onmogelijk is mits het gebruiken van één of andere plugin (secureFM) of kiosk mode.

Bovendien is de plugin om het menu te hiden volledig gratis te verkrijgen en is hij qua code oersimpel (één klik).

 

Wij blijven in Filemaker voor een hoop klanten ontwikkelen en pleiten voor meer standaardfunctionaliteit, m.a.w. het besparen van talloze workarounds, kosten en onderhoud. Wie dat niet doet is voor mijn part een fundamentalist met oogkleppen. Het grote verschil van FM en andere ontwikkelomgevingen is dat er nul komma nul wordt geluisterd naar behoeftes van ontwikkelaars en dat er geen enkel communicatiekanaal bestaat, we kunnen enkel wachten op wat het "regime" ons voorschotelt. Maar daar zit misschien een fundamenteel verschil in manier van denken: Filemaker beschouwt zich helemaal niet als een ontwikkelomgeving, meer als een "gebruiksvoorwerp", een “tool”. Dit besluit ik uit het feit dat ze zélf oplossingen aanbieden (lees: onder onze duiven aan het schieten zijn), en dat slechts een zéér klein deel wordt verkocht door hun partners en developers (nog geen 10%). Op een tiental kilometer van mijn voordeur is een zéér groot bedrijf gevestigd dat vorig jaar 1450 licenties van FM heeft aangekocht, en ik geloof niet dat daar veel "profesionele" ontwikkelaars mee gemoeid zijn.

 

Een kleine anekdote: toen ik een tijdje geleden op de bruiloft van mijn nichtje aan tafel verkondigde dat ik programmeur in Filemaker was, replikeerde mijn tante: “Filemaker? Dat gebruiken wij ook voor het ledenbestand van onze borduurclub!”. Got the picture? De drempel is té laag om serieus genomen te worden. Dit blijkt ook uit de kwaliteit van vragen hier. Versta me niet verkeerd, ik vind het in weze prachtig dat mensen de kans krijgen om meer te doen dan dat ze in Excel voor mekaar krijgen, maar vroeg of laat wordt het kaf van het koren gescheiden, en nog later loopt iedereen met FM met zijn neus tegen een muur, wat ze ook proberen.

 

Maar ik blijf zéér tevreden klanten hebben met een FM oplossing. En die glimlach en tevredenheid, daar gaat het tenslotte om. Maar we moeten druk uitoefenen om méér te krijgen dan dat ze ons bieden, dat is onze plicht als klant en verspreiders van het FM-evangelie. Zo zijn trouwens alle produkten groot geworden, door te luisteren naar de behoeftes van hun klanten.

 

Een domme vergelijking: toen de GPS-technologie uitkwam, waren er tal van autoradiomerken die van die opbouwschermen aanboden om in je wagen te plaatsen. Bij de lancering van het volgend model boden de automerken het zélf aan, netjes ingebouwd, ze dachten aan de nood van hun klanten. FM doet dit niet. Spijtig.

 

 

MVG

Stef

[Bonte]

Tja, met filemaker kan ik overweg en met die andere niet. Dat en het oersimpel opnemen van afbeeldingen (in JPG!) maakt het voor mij een nobrainer om bij FM te blijven zelfs met z'n beperkingen waar je vroeg of laat tegen botst. Er is veel bijgekomen in de 7 dus er is hoop, maar het is inderdaad iedere keer afwachten wat ze gaan opnemen en wat ze 5 jaar gaan uitstellen.

[Stef]

tja, "nobraining"... Ik kijk liever naar Canvas dan naar VTM. Kwestie van interesses alwaarschijnlijk.

[mikezwet]

Tja, met filemaker kan ik overweg en met die andere niet. Dat en het oersimpel opnemen van afbeeldingen (in JPG!) maakt het voor mij een nobrainer om bij FM te blijven zelfs met z'n beperkingen waar je vroeg of laat tegen botst. Er is veel bijgekomen in de 7 dus er is hoop, maar het is inderdaad iedere keer afwachten wat ze gaan opnemen en wat ze 5 jaar gaan uitstellen.

 

Ik zou me toch een beetje verdiepen in AutoIt http://www.autoitscript.com/autoit3/

 

Ben zelf beig met een database voor een telefoonkaarten verzamel vereniging waarvan elke lid eens in de zoveel tijd zijn bijdrage doet aan de catalogus in de vorm van een export bestand. Uiteraard moeten hierbij de plaatjes meegestuurt worden. Alle bestanden van alle gebruikers worden bijelkaar gevoegd tot 1 update die vervolgens weer word verstuurd en geimporteerd in de database van de gebruiker.

 

Er zijn wel een paar regels aan gebonden, bijv dat de gebruiker zijn plaatjes wel in de goeie map zet anders komen ze niet in de database. (Container is alleen een verwijzing)

 

Ik geloof dat het dit hetzelfde principe is van wat jij hebt met boeken?

 

Hier: http://www.autoitscript.com/autoit3/docs/tutorials/winzip/winzip.htm vind je bijv een uitleg over hoe je automatisch winzip kan installeren. Dit script kan je laten beginnen in fm door een send event.

 

Je hebt dan de mogelijkheid om een geexporteerd bestand(en) met bijv plaatjes in te pakken in een winzip zodat dat meteen te mailen is. Nog verder.... meteen automatisch mailen.

 

Ook andersom meteen vanuit filemaker uit te pakken is. Dus de gebruiker zoekt via een container het update bestandje op, dit path word opgeslagen in een textveld die het autoit script vervolgens kan gebruiken om het winzip bestand uit te pakken en te plaatsen op de goede locatie.

 

Kortom, mogelijkheden genoeg met AutoIt, alleen weer even je eigen erin verdiepen

[Bonte]

Ik werk volledig op Mac dus ik laat scripting maar voor wat het is. Met afbeeldingen importeren en updates aanmaken/invoeren heb ik geen probleem maar het was gewoon handiger mocht bovengenoemde oplossing mogelijk zijn.

Die ZIP mogelijkheid ziet er ook leuk uit maar is moeilijk te integreren in 2 platformen. Wat ik graag gebruik is de mogelijkheid om rechtstreeks te importeren van een XML file die op m'n site staat, handig voor de officiële updates zeg maar.

[Arnoud]

@Stef,

 

Tja Stef, het zou ook zo kunnen zijn dat je je als 'overloper' aangesproken voelt natuurlijk. Hetgeen ik slechts wilde zeggen is dat niet alleen bij FM maar ook bij andere platformen voor extra functionaliteit (plugins) betaald moet worden. Maar goed ik denk dat je nu wel een keer goed de gelegenheid hebt aangegrepen om je punt(en) voor eens en altijd scherp voor het voetlicht te werpen.

Er zijn in dit forum behoorlijk wat Servoy gebruikers en daar is niets mis mee. Servoy is in sommige dingen / situaties gewoon een betere keuze dan FM, maar omgekeerd geldt ook (right tool for the right job).

FM inc. zou een voorbeeld kunnen nemen aan de wijze waarop Servoy naar haar gebruikers luistert. Aan de andere kant: Servoy moet natuurijk wel, om zieltjes te winnen. Filemaker zou dit moeten doen om de drain van developers tegen te gaan. Wat je zegt over de lage instapdrempel van Filemaker is grappig en dat doet me terugdenken aan de DOS tijd: toen werden die code tikkers nog voor experts aangezien. Tegenwoordig schuift iedereen met een muis. Er is op zich niets mis mee dat iedereen een (eenvoudige) database zou kunnen opzetten met Filemaker, maar ja als je daarvan je werk hebt gemaakt dan is de uitstraling als programmeur niet meer zo groot, ook al ben je in staat om complexe applicaties te bakken.

Het is evident dat jij aan dit forum geen bijdragen meer zou leveren als FM je niets meer zou doen (zakelijk of emotioneel).

Ik hoop dat je dat wel blijft doen en wat mij betreft mogen dat flinke kritische opmerkingen zijn, in de hoop dat daar wat mee gedaan gaat worden. Dus Hilde en overigen, doe wat met deze opmerkingen.

 

groetjes,

 

Arnoud

[DTPerry]

Misschien is de gratis Shell plugin wel iets.

Ik weet alleen niet of het bij een update nog wordt gesupport of dat je het met developer kan imbedden

 

SHELL plugin

mac-> http://www.abstrakt.com/files/shell.sea.hqx

win-> http://www.abstrakt.com/files/shell.zip

 

hiermee kun je onder osX alle commando's aan die je ook in de terminal kunt. (heb er nog geen windows ervaring mee)

 

je kunt dus ook files kopieren naar een specifieke plaats met een specifieke naam. Deze naam kun je dan gebruik in je scriptstap om automatische de afbeelding te importeren.

 

ik gebruik deze plugin om afbeeldingen van het internet te halen, schermafbeeldingen van PDF bestanden te maken met een bepaald formaat en deze als jpg te importeren in een container veld.. samen met wat applescript is eigenlijk alles mogelijk wat de troi-file-plugin ook kan (en meer)

 

het eerste FM windows virus:

External ( "shell-Execute"; "Format C:" )