Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 06.08.2005 - 12:14 Titel: FRONTMOST PROGRAMM an FileMaker übergeben mit Variable |
|
|
KURZ-re-EDIT:
Die Parameter der Versuchsreihe sind so:
OS9.2.2 , Smile 1.8.4 Scripteditor D1-1.6 :
Tastaturkürzel = F7=Skript-Auslöser des:
Skript "F7" mit Speicherort:
STARTNAME & ":" & ¬
"Systemordner:Scripts:Universal Scripts:F7"
Probleme 1-2:
1. Wenn im Moment des Druckes auf die F7-Taste mittels OSA Menu der Finder = Frontprogramm ist, dann:
entsteht Fehler "-1712 AppleEvent time out "
Falls aber irgend ein anderes Programm=Frontmost, dann ensteht der Fehler nicht
2. MASSIV_BUG, ( ebenfalls auf OSX nicht existent):
man kann keinen einzigen Tell Block mehr ins Skript F7 geben und damit kann ich die Variable FrontProgr nur mit dem CLIPPER-BOARD an die aufgerufene FileMaker Datei übergeben
Zitat: | -- §1.4 FMAUSW °°inMENU_Coden_F7
--1.4 FMAUSWAHL°°inMENU_Coden_F7
-- ==================================================
global PFAD1, Win1
property APA1 : "AllDruckerwahl.APA"
property FMSCR1 : "FMSöAllDruckerwahl"
property VaWinName1 : "VaWinName1"
property cellVaProg : "VaProg"
property cellVaProEXT : "VaProEXT"
global STARTNAME, FrontProgr, AppFM, PfFileAllDruckerwahlAPA
-- ==================================================
set STARTNAME to (first item of (list disks)) as string
set PfFileAllDruckerwahlAPA to STARTNAME & ":" & ¬
" ALLE_öffner:AllDruckerwahl.APA"
set PfFileF7 to STARTNAME & ":" & ¬
" ALLE_öffner:PRAKTISCH!:9999HANDLERS:F7"
-- ================= TOP für OS9!!! =====================
set FrontProgr to (path to frontmost application as text)
set the clipboard to FrontProgr
if FrontProgr contains "finder" then
try
open file PfFileAllDruckerwahlAPA
on error Fehlermeldung number Fehlernummer -- -1712 AppleEvent time out
display dialog ((Fehlernummer) as string) & " " & Fehlermeldung ¬
buttons {"ABBRUCH", "WEITER"} ¬
default button ¬
"WEITER" with icon 1 ¬
giving up after 1 --was wäre denn unendlich kurz? 0 ist unendlich lang ebenfalls ""
-- icon= 0=>Hand--1=>Sprechblase2 =GelbesDreieck
end try
else
tell application "Finder" to open file PfFileAllDruckerwahlAPA
end if |
--tell application "FileMaker Pro" to set cell cellVaProg of window APA1 to FrontProgr as string--JA NICHT auf OS9.2.2.!!!!!!!!!!!!!! choost zuerst im fileMaker-firts open Programm herum
"ich bin total verzweifelt und sehe AppleSkript nicht mehr als meine lieblings - Skriptsprache an, da ich sowieso nur eine kenne: AppleSkript, das wäre ohne @Snow&/orFolker&/or Euch Skriptern in Snows Forum ein schwacher Trost"
(*
tell application FrontProgr
(*
tell application "FileMaker Pro" to (open file PfFileAllDruckerwahlAPA) activate
--tell application "FileMaker Pro" to set the clipboard to FrontProgr
tell application "FileMaker Pro" to set cell cellVaProg of window APA1 to FrontProgr as
string
*)
F7(FrontProgr) of (load script file PfFileF7)
end tell
*)
ich hab wirklich alles probiert was in meinen Kräften und Kenntnissen steht: auch das Skript zu splitten und ein anderswo gepostetes aufzurufen, dasselbe Problem, der Launch-Effekt ist schuld am ganzen Desaster da der Script Editor mit dieser Art des Startes nicht die Programme die er mit tell Blöcken meistern müsste, nicht mal den Finder, sich merken kann. Scheusslich , umso mehr als man das Frontprogramm NUR mit dem Launch-Effek t(OSA-Menu) auf vernünftige Art erfahren kann(unvernünftige hab ich auch gemacht, die schäm ich mich zu zeigen da sie ziemlich lange rechnerzeit in anspruch nehmen, mit dem wärs dann allerdings geklappt..) _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius
Zuletzt bearbeitet von spirigwi am 10.12.2005 - 15:08, insgesamt 3-mal bearbeitet |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 06.08.2005 - 17:40 Titel: |
|
|
Hoffnung:
man könnte doch anstatt Clipboard auch im Skritp des Frontmosters Variablenwerte für Frontmost Programm und zusätzlich window 1, falls FileMaker front macht deponieren( in Property oder Globale?) so wie in Snows "Aufräumen" ps mein absolutes Lieblingsskript mit verewigtem Konterfei Snowens.
Dann aus dem Filemaker heraus ein anderes AS starten das die 2 Daten dort herausholt?
ZB:
set VaListF7k to F7ProAbfrage() of (load script file PfFileF7Starter)
und das Ziel wäre dann im "Frontmoster-Skript drin:
ZB ;
on F7ProAbfrage( ) --oooooooooooooooooooooo
--hier zum variablen von aussen zu pflücken
get FrontProgr
--set VaListF7 to {FrontProgr, Win1}
return VaListF7
end F7ProAbfrage
SNow, das bring ich unmöglich hin, wäre für mich dann aber eine Jahrhundertlösung dieses leidigen Drucker-Auswahl-Problems
Ganz kurz das Ziel davon: normal nimmt man auf OS9 die auswahl: zu schwierig und oft nicht nötig und: man vergisst das Programm aus dem man Auswahl gemacht hat
fileMaker-Pseudoauswahl mit allen schickanen und bildern und funktionen fhelt mir nur noch Trick um nach der Druckerschlacht mit Bildlein sich ins startprogramm zurückjetten lassen. Das da oben ist schon haarscharf dran, nur eben über Clipboard und die Umständlichkeit aus diesem wiederum 2 Variablen herauszupflücken(Frontprogramm und window 1 des FileMakers) _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 09.08.2005 - 22:32 Titel: Problem gelöst |
|
|
Da die Frage nach:
Wie holt man eine in AppleSript_A generierte Variable mittels AppleSript_B in das AppleSript_B herüber?
für Euch derart einfach ist, nehm ich wohl an dass sie in AS-ABSOLUTE-BASICS gehört.
ja dann halt meine Lösung(in den letzten 36 h erkrampft aber nirgends gefunden in den Absolut-Anfänger und links der linke kann man ja nicht einfach Fragen stellen nur Werte tippen man müsste schon eine Kapitelüberschrift oder sowas für ganz bescheuerte wie mich finden) :
(Wenn man script A und script B jeweils einfach als Script, nicht mal als Programm, auf Schreibtisch legt kann mans sogar überprüfen, dass die technik nur mit Propertys und NICHT mit Globals funktioniert womit eigentlich bewiesen wäre dass die pseuoenglische Bezeichnung global ein non-sens ist und dann erst ins groteske entartet wenn ScriptEditors ERROR so heisst: "Can`t declare XXXXXX as both a local and global variable." So abgetippt!)
Zitat: | property Scriptname : "A"
property PropertyVARIABLE : "PropertyVARIABLE"
global GlobalVARIABLE
----------------------------
set GlobalVARIABLE to "GlobalVARIABLE"
my GibVariableEINA()
on GibVariableEINA()
display dialog "A 1.dialogt: " & PropertyVARIABLE
display dialog "A 2.dialogt: " & GlobalVARIABLE
end GibVariableEINA |
Zitat: | property Scriptname : "B"
my GibVariableEINB()
---------------------
on GibVariableEINB()
set PfFile to ((first item of (list disks)) as string) & ":" & ¬
"Desktop Folder:A"
GibVariableEINA() of (load script file PfFile)
end GibVariableEINB
|
PS: diese AS-Struktur erlaubt mir nun den grässlichen OS9 BUG zu lösen, dass nämlich ScriptEditor nicht beides kann : launchen aus OSA-Menu und dann die Variablen in andere Programm-Fenster verteilen da es keine tell-Block mehr aufrufen kann , zwar stümperhaft, aber immerhin zur absoluten Freude meiner Wenigkeit
Vielleicht gibts ja eine einfachere Lösung als das Variablen-pflücken aus einem AS-Skript mit anderem AS-Skript von dessen Realisierbarkeit ich ehrlich gestanden bisher nicht ein einziges Beispiel angetroffen habe
(oder hab ich falsch gesucht? oder bin ich jetzt aufs Niveau der NASA gesunken die zum Beweis der Bauchoperation ihres space-shuttles ein für die Landung unnötiges Filterpapier zwischen 2 Teflonkacheln herausoperiert und laut verkündet jeden Kachel-Defekt im All reparieren zu können?) _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius |
|
Nach oben |
|
 |
Snow Administrator


Anmeldedatum: 21.11.2000 Beiträge: 1946 Wohnort: Deiningen
|
Verfasst am: 09.08.2005 - 23:10 Titel: Re: Problem gelöst |
|
|
spirigwi hat Folgendes geschrieben: |
(Wenn man script A und script B jeweils einfach als Script, nicht mal als Programm, auf Schreibtisch legt kann mans sogar überprüfen, dass die technik nur mit Propertys und NICHT mit Globals funktioniert |
Das ist ja wohl logisch. Properties behalten ihren Wert auch nach Beendigung des Skripts - so lange bis das Skript neu kompiliert wird.
Properties benötigen keinen 'set'-Befehl, um zu existieren. Es genügt die Definition
property: WERT
Eine globale Variable existiert erst, wenn sie durch 'set' oder 'copy' initialisiert wurde und das Skript ausgeführt wird. Die Deklaration als 'global' bewirkt noch gar nichts.
Wenn du das Skript B nur lädst, besteht die globale Variable noch gar nicht. Also kannst du auch deren Wert nicht abfragen.
Allerdings kannst du dir das externe Skript in eine Variable laden und dann erst mal ausführen lassen. Dann besteht auch für die globale Variable ein Wert, den man abfragen kann.
Mehr zum Thema hier:
http://www.fischer-bayern.de/phpBB2/viewtopic.php?t=502 _________________ Peter
-
Fischer-Bayern.de|Shadetreemicro.com |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 09.08.2005 - 23:14 Titel: |
|
|
Moment: snow hat Folgendes geschrieben: |
Wenn du das Skript B nur lädst, besteht die globale Variable noch gar nicht. Also kannst du auch deren Wert nicht abfragen. |
genügt es dann nicht wenn ich sie wie oben gezeigt zuerst im Script A beschreiben lasse mit set ...?
Das vezwickte an der sache ist doch wohl ,dass ich mit misto ein skript bastle das auch globals alledings im selben Skript , Speicherwerte zuordnet und beim nächsten Aufruf diese offenbar frei gibt, sonst käme nämlich dieselbe Error-meldung wie Skript B in der Zeile die sagt dass die "Variable global nicht existiert"
Dank für den link, Snow, so einfach ist das wohl gar nicht mit diesen externen Skripts wo 2 untereinander Infos austauschen. allerdings in meinem Fall käme ich mit speichern eines AS aus A heraus wiederum nicht weit da man ja für den Pfad den Finder bemühen müsste und auch das load-Skript in A nicht funktioniert! Somit umgehe ichs mit einem 2. Handleraufruf aus dem FM heraus, der dann die Variablen des A herausholen soll.
Nur noch kurz: meinst du dass ich mit diesem A+B Modell das Ding mit dem launcher lösen kann?
Ich würde dann vom launcher einfach A aufrufen lassen, dort die Variablen in property schreiben für: name of window 1 des FileMakers und andererseits application Frontprogramm und diese mit B aus dem FileMaker wieder hereinholen, auf 2 Felder verteilen, die dann vom jeweiligen Objekt ein Grafik-Bild abgeben (ZB vom Word das Bild eines stinkenden Exkrementes u.s.w)  _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 10.08.2005 - 00:47 Titel: |
|
|
Es geht geht :A als Programm-gespeichert, Tastaturkürzel.
Zitat: | property Scriptname : "A"
property TexAntwDia1 : "TexAntwDia1"
----------------------------
set DsplDia to display dialog "Gib ein:" default answer "hierdrüber"
set TextButtAntw to {}
set TextButtAntw to ¬
{text returned, button returned} of DsplDia
set TexAntwDia1 to item 1 of TextButtAntw
set ButAntwDia1 to item 2 of TextButtAntw
my GibVariableEINA()
on GibVariableEINA()
display dialog "A 1.dialogt: " & TexAntwDia1
--display dialog "A 2.dialogt: " & GlobalVARIABLE
return TexAntwDia1
end GibVariableEINA
|
Zitat: | --
property ScriptnameB : "B"
my GibVariableEINB()
---------------------
on GibVariableEINB()
set PfFile to ((first item of (list disks)) as string) & ":" & ¬
"Desktop Folder:A"
set a to GibVariableEINA() of (load script file PfFile)
return a
end GibVariableEINB
|
Wenn als Smile Dokument gespeichert , wird die Property trotz Skriptaufruf nicht umgeschrieben
Wenn mit Tastatur aus OSA Menu gestartetes A-Skript kenne ich Res. ZZ noch nicht! _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius |
|
Nach oben |
|
 |
Snow Administrator


Anmeldedatum: 21.11.2000 Beiträge: 1946 Wohnort: Deiningen
|
Verfasst am: 10.08.2005 - 01:05 Titel: |
|
|
spirigwi hat Folgendes geschrieben: |
genügt es dann nicht wenn ich sie wie oben gezeigt zuerst im Script A beschreiben lasse mit set ...? |
Nein, habe ich doch eben beschrieben warum das so ist. Die Variable und der ganze Rest vom Skript existiert erst, wenn das Skript läuft.
Die Ausnahme hierzu bilden die Properties. Sie existieren ab dem Zeitpunkt wo das Skript kompiliert wird. Wenn du also ein kompiliertes Skript speicherst, sind die Werte der Properties bereits vorhanden und auch gespeichert - und auch abrufbereit.
Der Rest des Skripts ist NICHTS. Sonst müsste man ja kein Skript laufen lassen und es würde genügen, wenn man den Skripttext schreibt.
spirigwi hat Folgendes geschrieben: |
Das vezwickte an der sache ist doch wohl ,dass ich mit misto ein skript bastle das auch globals alledings im selben Skript , Speicherwerte zuordnet und beim nächsten Aufruf diese offenbar frei gibt, sonst käme nämlich dieselbe Error-meldung wie Skript B in der Zeile die sagt dass die "Variable global nicht existiert" |
Das geht doch nicht. Globals existieren nur zur Laufzeit des Skripts. Es kann nichts gespeichert werden, was dann beim nächsten Aufruf noch vorhanden wäre.
Das ist Sache der Properties!
spirigwi hat Folgendes geschrieben: |
Dank für den link, Snow, so einfach ist das wohl gar nicht mit diesen externen Skripts wo 2 untereinander Infos austauschen. |
In meinem letzten Beitrag im genannten Thread ist alles drin, was man braucht:
- ein Skript wird von einem anderen Skript aus angelegt
- in diesem neu angelegten Skript werden von einem anderen Skript aus Werte gespeichert
- von einem weiteren Skript aus werden die gespeicherten Werte des 'Preferences'-Skripts wieder abgerufen.
Man muss ja nicht alle drei Möglichkeiten nutzen - das 'Preferences'-Skript kann man ja auch selbst anlegen - und nicht per Skript.
Aber die Möglichkeiten sind alle aufgezeigt. Hast du die drei Beispiele schon ausprobiert?
spirigwi hat Folgendes geschrieben: |
Nur noch kurz: meinst du dass ich mit diesem A+B Modell das Ding mit dem launcher lösen kann?
|
Mir ist ehrlich gesagt überhaupt nicht klar, was du überhaupt machen willst. _________________ Peter
-
Fischer-Bayern.de|Shadetreemicro.com |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 10.08.2005 - 21:20 Titel: |
|
|
mein Vorhaben Ziel :
mit in OSA-Menu gelegtem Skript( A ) --> Frontmost-Programm ermitteln. Mittels Tastenkürzel( F7) erfolgt Aufruf des A welches olf Funktionen tätigen soll:
--> Name Frontmost-Programm ermitteln, als Wert in Variable geben--> Variable FileMaker übergeben -->mittels: in cell "FrontProgrammName" ablegen
-->Zweck des ganzen: beim Start aus dem FileMaker heraus(re-Edit: wenn das "Rückführungs-AS im FileMaker-File gesatartet wird) kann dies AS so sagen: tell application "FrontProgrammName" to activate , dann ist man wieder im Frontmost-Programm
tönt doch ganz einfach, nicht? auf OSX schon, da hilft der Hausverstand und ist sicher nicht der Rede wert und würde auch nicht eine Frage in snows Forum verdienen ich würde mich sogar lächerlich machen so etwas banales überhaupt zu fragen.
Dasselbe auf OS9.2.2 ein Desaster:
Nur Skript A kann ja FrontmostProgramm ermitteln, deshalb liegts ja auch im OSA Menu. Was es NICHT zusätzlich kann auf OS9 ist dann folgendes:
Snow hat Folgendes geschrieben: | - ein Skript wird von einem anderen Skript aus angelegt | Wenn jetzt also A = das anderen Skript wäre, kann das in OSA gelegte Skript A , das den Frontmost ermittelt, nicht anschliessend folgendes machen:
tell application "FileMaker Pro"
set cell "FrontProgrammName" to FrontProgrammName of window 1
--das sind FileMaker spezifische Befehle und werden von keinem anderen Programm im tell-Block respektiert, ausser: window 1. in therms of..geht auch nicht da "FileMaker Pro" nicht kompiliert werden kann und das Anwählen von "FileMaker Pro" scheint das Problem nun zu sein auf OS9
end tell
damit kann es auch kein Skript auf Finder anlegen. Ich stecke also in einer Sackgasse, da nicht einmal dieses ginge:
Snow hat Folgendes geschrieben: | - in diesem .... angelegten Skript werden von einem anderen Skript aus Werte gespeichert |
könnt ihr dieses Problem lösen?
Mein Plan: ich löse das Problem so, dass ich die Information der Variablen FrontProgrammName die im A liegt mit einem AppleSkript B heraushole.
Um diese Lösung zu prüfen, lege ich in A ein "Text-Ausgabe-Dialog, den ich testmässig immer variiere, um beim Ablauf des B die in A vorher eingegebenen Werte zu prüfen. Diesen Schritt also:
Snow hat Folgendes geschrieben: | - von einem weiteren Skript aus werden die gespeicherten Werte des 'Preferences'-Skripts wieder abgerufen. | das wäre bei mir das Skript B welches den Wert aus A herausholt.
Mein Modell sieht so aus:
23 h46 re-edit alleGlobals heraus, Frontmost-Funktion EIN hat Folgendes geschrieben: | property Scriptname : "A"
property TexAntwDia1 : "TexAntwDia1"
property FrontmostP : "FrontmostP"
----------------------------
--on run
--(*
set DsplDia to display dialog "Gib ein:" default answer "hierdrüber"
set TextButtAntw to {}
set TextButtAntw to ¬
{text returned, button returned} of DsplDia
set TexAntwDia1 to item 1 of TextButtAntw
set ButAntwDia1 to item 2 of TextButtAntw
--*)
set FrontmostP to (path to frontmost application as text)
my GibVariableEINA()
--end run
on GibVariableEINA()
display dialog "A 2.dialogt: " & TexAntwDia1 & " ____ " & FrontmostP
return TexAntwDia1 & " ____ " & FrontmostP
end GibVariableEINA |
Zitat: | property ScriptnameB : "B"
my GibVariableEINB()
---------------------
on GibVariableEINB()
set PfFile to ((first item of (list disks)) as string) & ":" & ¬
"Desktop Folder:A"
set a to GibVariableEINA() of (load script file PfFile)
return a
end GibVariableEINB |
Wenn man also A aus A heraus startet, kann man den dialog default answer überschreiben, ZB mit 1, dann wird 2 mal die 1 dialogisiert in A
Wenn man danach B startet, wird 2 mal "TexAntwDia1" dialogisiert , und nicht 1.
Das ist logisch da du ja sagst es wird nur derjenige Wert gespeichert, der beim Kompilieren in die Property geschrieben wird und das ist halt "TexAntwDia1". Das schreibt auch Folker(als Nachteil seiner einmal vorgeschlagenen Methode in deinem link)
So: um nun einen sinnvollen, aktuellen Wert im Skript A speichern zu lassen(die 1), in meinem Fall wär dies der Name des FrontmostProgramms, der dann durch B - Skript dialogisiert wird, zu erhalten, hab ich folgendes Vorgehen ausprobiert:
Skript A nicht aus A heraus aufrufen , sondern mit einem Tastenkürzel. Da ich ein Tastenkürzel innerhalb von 3 sec vergeben habe, darf man mir das glauben, ich habs wirklich ausprobiert. Resultat: B liefert immer denjenigen Wert den man in A beim jeweiligen dialog. Durchlauf dort eingegeben hat. Dabei kann A auch auf dem Schreibtisch gespeichert sein , falls man nicht das FrontmostProgramm ermitteln will.
Den Effekt des Tastenkürzels kann ich auch erreichen wenn ich ein on run und end run setze und einfach auf dem Schreibtisch ins A doppelklicke (dann öffnet es A, spielt den Dialog durch und merkt sich die überschrieben Default-Antwort(=1), welche dann durch B abrufbar wird und nun auch so aufgerufen 1 heisst.
Vorteil dieses Vorgehens: es muss kein AS auf Platte zusätzlich gespeichert
werden, A (im OSA-Menu) und B (im FileMaker) würden wunschgemässlaufen
Weit gefehlt: trotz on run - Struktur im A,das im OSA Menu gespeichert ist, wird die Variable nur dann aktualisiert, wenn man es mit Tastenkürzel aufruft (ZB F7)
Wenn ichs direkt im OSA-Menu anklicke, behält es den vorletzten Wert.(da ja offenbar der on run Befehl übersprungen wird durch anklicken im OSA-Menu?
Was passiert nun wenn ich es nicht in on run Struktur packe und direkt durch Klick ins OSA-Menu aufrufe? _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius
Zuletzt bearbeitet von spirigwi am 21.12.2005 - 23:39, insgesamt 6-mal bearbeitet |
|
Nach oben |
|
 |
Snow Administrator


Anmeldedatum: 21.11.2000 Beiträge: 1946 Wohnort: Deiningen
|
Verfasst am: 11.08.2005 - 01:10 Titel: |
|
|
spirigwi hat Folgendes geschrieben: | -->Zweck des ganzen: beim Start aus dem FileMaker heraus kann AS im Bedarfsmoment so sagen: tell application "FrontProgrammName" to activate , dann ist man wieder im Frontmost-Programm
|
Beim Start aus FileMaker heraus ist FileMaker das frontmost Programm. Was gibt's denn da groß zu ermitteln? _________________ Peter
-
Fischer-Bayern.de|Shadetreemicro.com |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 12.08.2005 - 08:18 Titel: |
|
|
AllDruckerwahl.APA , ein FM file ist bei mir ein FM file welches einzig den Zweck hat die Druckerfragen zu managen: Auswahl der Drucker, Installation der Drucker, Desinstallation Hilfsprogramme der versch Drucker, Internet Seiten der drucker(ZB HP)
Zugang mit Bild in die Auswahl(braucht man für Label-Drucker und gewisse USB-Drucker in ganz bestimmten Fehler-Situationen, rutinemässige Umstellungen in auswahl besorgt mir AS welche in AllDruckerwahl.APA , ein FM file gespeichert sind)
Snow hat Folgendes geschrieben: | spirigwi hat Folgendes geschrieben: | -->Zweck des ganzen: beim Start aus dem FileMaker heraus kann AS im Bedarfsmoment so sagen: tell application "FrontProgrammName" to activate , dann ist man wieder im FrontProgrammName-Programm
|
Beim Start aus FileMaker heraus ist FileMaker das FrontProgrammName Programm. Was gibt's denn da groß zu ermitteln? |
Ich wollte damit folgendes sagen:
Kurz-reEdit:
Dass dem F7 Tastaturkürzel-Skript auch mitgeteilt werden muss, dass man F7 dann gedrückt hat, als FileMaker Pro als Programm im Vordergrund gestanden hat.
Als 2. Information will ich dem F7-Script auch mitteilen, welches FM-Fenster im Vordergrund gestanden hat im Moment des Tastatur-Druckes:
Somit erhält das file AllDruckerwahl.APA 2 Informationen, welche seinem AppleSkript wiederum zur Verfügung stehen: es kann nun dieses FM-window anwählen, welches im Moment des Tastendruckes F7 im Vordergrund gestanden hat.(bei mir gibt es ca 44 solcher FM-windows!) _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius
Zuletzt bearbeitet von spirigwi am 11.12.2005 - 12:24, insgesamt 2-mal bearbeitet |
|
Nach oben |
|
 |
spirigwi •----->


Anmeldedatum: 10.07.2003 Beiträge: 1517 Wohnort: Olten-CH
|
Verfasst am: 11.12.2005 - 12:19 Titel: OSA-Menu bug! |
|
|
KURZ-Re-Edit:
In der Zwischenzeit bemerkte ich, dass ich einem BUG zum Opfer gefallen bin :
Eigentlich sollte ja das OSA_Menu (==-Skript Menu) fähig sein, das Frontprogramm anzugeben(da es launch-Fähigkeiten haben sollte)
Nun, das OSA Menu scheint ein Programm zu sein:
OSA_Menu1.2.3d7 wird auf Snows download- liste angeboten.
Schön und gut wenn man OSA_Menu1.2.3d7 installiert hat, dann genügt der Befehlscode:
set FrontProgr to (path to frontmost application as text)
Damit würde problemlos diejenige frontmost application in eine Variable rutschen, welche beim Druck auf die Taste F7 auch wirklich im Vordergrund steht, selbst wenn sie "Finder" hiesse.
Ich hoffe als allgemein bekannte Tatsache voraussetzen zu können, dass ein AS, welches die frontmost application ermitteln soll mit dem Satz:
set FrontProgr to (path to frontmost application as text), natürlich nur dann ein sinnvolles Resultat liefert, wenn das AS aus dem OSA-Menu oder bei OSX aus Script-Menu, aufgerufen wird (es genügt auch ein Alias davon in den Universal-Script-Ordner/resp. Script-Ordner zu legen)
Hat man aber OSA_Menu << 1.2.3d7-Version installiert, tritt nun genau dieser BUG auf:
Für den Spezial-Fall nämlich, dass die frontmost application = "Finder" heisst, ensteht der BUG (und noch einiges weniges mehr), was genau zu meinem Problem geführt hat. Die Beschreibung der exakten Verhältnisse war mir zu schwierig. Es gibt im diesem Forum auch nicht 1 Beispiel, welches denselben Fehler berschreibt. Ausnahme: diejenigen Forumsanfragen, welche meine frontmost application - Fragen behandeln. Weil ich bis jetzt diesen bug nicht gekannt habe, kamm es immerwieder zu unterschiedlichen Ergebnissen zwischen Snow und mir und das hatte nichts mit Verwechslungen oder Formulierungsschwächen meinerseits zu tun sondern mit diesem versteckten Bug.
Nun könnte man sagen: OSA_Menu1.2.3d7 montieren!
Falsch für mich, weit gefehlt!
Die 1.2.3d7 - Version hat nämlich den gravierensten Nachteil den ich mir für das OS9 vorstellen kann:
OSA_Menu1.2.3d7 ist als eines der einzigen wenigen Tools nicht mehr voll kompatibel mit "Now-Menu´s" Fähigkeit der direkten Tastatur-Kürzel-Zuordnung, und zwar ausgerechnet im OSA_Menu1.2.3d7 kann man diese Zuordnung nicht mehr machen. Diese "Now-Menu"-Eigenschaft ist für mich aber unverzichtbar auf OS9 wie auch auf CLASSIC, weswegen ich mein Skript etwas kompliziert ausformulieren musste, es nun aber tadellos seinen Dienst leistet trotz dieser erwähnten Einschränkung.(1. Verzicht auf einen tell-Block 2. übermitteln der Variablen-Werte über die Clip-board-Funktion, welche wiederum auf OS9 problematisch ist)
D.h. : Problem gelöst, und wiederum Dank der geduldigen Hilfe-Leistung von Snow.
Hugh sprach ich, der Appachen-Rauchzeichen-AS-Kräuterdoktor, einer Ehrenbezeichnung, die ich noch so gerne PI zu verdanken habe. (wie man hoffentlich sieht, hab ich mir alles zu Herzen genommen betr. Formulierung)
PS: darf ich bitten? Falls jemand möchte, dass solcherart Infos wie Bugs von AppleSkripts, nicht in Snows Forum gehören, möge er sich doch bitte hier melden? Über den Weg wie man solche bugs überhaupt herausfinden kann mögen sich die Geister teilen, da gibt es mit Sicherheit professionellere Methoden als die Anfrage in einem AS-Forum  _________________ Skript-Fan => ein � -Fan =>Scr¿¿-KongFuSius_Kurpfusius |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2002 phpBB Group Deutsche Übersetzung von phpBB.de
|
|
|