FFScripting-Maschine

Hallo, Werner

ich kann das mangels Program-Masse im Detail nicht nachvollziehen.
Eines muß ich aber leider konstatieren: Was Du da machst, ist Quark und hat mit sauberer Programmierung nicht die Bohne zu tun. Ich hoffe, Du bist mir jetzt nicht verärgert. So wie ich es Dir aufgeschrieben habe, ist es als Gerüst richtig, ich habe das schon ein halbes Dutzend mal gemacht, auch mit mehrfach verschachtelten Dialogen. Irgendwo hast Du ein anderes Problem. Schick mir den Code, dann bringe ich es zum Laufen.

Gruß Jochen

Nachtrag:

Ich bin ein gemeiner Fetzen. Nur noch zur Erklärung: Den Teil oberhalb des ersten Lattenzauns benutzt Joachim, um die Maskenparameter und -werte zu bunkern. Beim ShowDialog werden diese verwendet für die Anzeige. Es ist also überflüssig, diese wieder und wieder zu löschen und wieder aufzubauen. Das kostet richtig Zeit. Der SetControl wird auf einem vorhandenen Control ausgeführt und beim Show angezeigt, solange man nicht die Maske abbaut.
In Case Else darfst Du gar nichts unterbringen, dahin kann das Script eigentlich ums Verrecken nicht kommen.
 
Hallo J.K.,

möchte einen bestimmten Pfad voreinstellen in FF_EnterPath, FF_EnterFileName.

Momentan ist nur das Explorer-Verzeichnis oder das Rootverzeichnis einstellbar.

Nun gibt es zwei Möglichkeiten: Entweder durch Vorgabe eines Pfades als Parameter, oder durch Parameter das CurrentDirectory einzustellen. Dieses kann man per Script beeinflussen und führt zum selben Zweck. Übrigens: wenn man EnterPath abbricht springt es automatisch zum CurrentDirectory. Vielleicht ein Wink?


Nachtrag: @Jochen - betrifft Nachtrag
... Nur noch zur Erklärung: Den Teil oberhalb des ersten Lattenzauns benutzt Joachim, um die Maskenparameter und -werte zu bunkern. Beim ShowDialog werden diese verwendet für die Anzeige. Es ist also überflüssig, diese wieder und wieder zu löschen und wieder aufzubauen. Das kostet richtig Zeit. Der SetControl wird auf einem vorhandenen Control ausgeführt und beim Show angezeigt, solange man nicht die Maske abbaut.
In Case Else darfst Du gar nichts unterbringen, dahin kann das Script eigentlich ums Verrecken nicht kommen.
Zum Vergrößern anklicken....
Ich rede nicht, bevor ich es ausprobiert habe. Ich bin im Else gelandet, warum auch immer und darin verreckt, so das nur die "Dreifingerfunktion" half. >:(
Wenn Du die Maske stehenläßt, wird zwar der Dialog angezeigt, aber nicht die Variablen die während des bestehenden, angezeigten Dialogs geändert wurden; es sei denn manuell über Tastatur und Maus. Da hilft momentan nur das Zerstören und neu aufbauen, wie Zaph es erwähnt hat, leider :(.


Schönen Gruß,  ;)

W.P.
 
Bin ja schon fertig mit der Testerei.

Dein Script, auf den Minimalkern zusammengeschrumpft, funktioniert an 3 Stellen gleichzeitig nicht. Du kannst offensichtlich nichts für die Malesse. So wie es da steht, sollte es funktionieren. Vielleicht  übersehe ich etwas wegen müde, aber ich glaube eher, daß da wieder  mal ein Pointer auf einen Pointer auf ein Array von Pointern im Scriptbereich oder in FF sein Unwesen treibt. Der Fluch der Menschheit, ich werde nie begreifen, wie dieser Stroustrup-Unhold darauf verfallen ist, Programmierer als Precompiler zu mißbrauchen.


option explicit

Dim dlgTitel
Dim varPfad
Dim tbxPfad
Dim btnPfad

tbxPfad="Textbox"
varpfad=""
btnPfad="Button"

FF_AddDialog dlgTitel, 200, 85
FF_AddControl dlgTitel, tbxPfad, "EDIT", 3, 57, 100, 10
FF_AddControl dlgTitel, btnPfad,"BUTTON", 183, 57, 12, 10

do      
     Select Case FF_ShowDialog (dlgTitel)
               Case "OK"
                         varPfad=FF_GetControl(dlgTitel,tbxPfad)      
                         msgBox "varPfad = " & varPfad
                               FF_SetControl dlgTitel, tbxPfad, "OK"     '<<< Keine Textausgabe
               Case "CANCEL"
                     msgBox "Cancel"
                               exit do      
                Case btnPfad
                     varPfad = FF_EnterPath(False, "Wählen Sie den Zielpfad aus") '<<< BOOL kein Einfluß auf Startverzeichnis  
                     msgBox varPfad
                     FF_SetControl dlgTitel, tbxPfad, varPfad '<<< Keine Textausgabe
                Case Else
                     msgBox "Huch!"
       End Select
loop

FF_CloseDialog dlgTitel


@Joachim: Kannst Du das vielleicht in den Debugger nehmen und sehen, was auf Deiner Seite so los ist? Mir fällt dazu nichts mehr ein.

Gruß Jochen
 
Hallo J.K.,

möchte einen bestimmten Pfad voreinstellen in FF_EnterPath, FF_EnterFileName.

Momentan ist nur das Explorer-Verzeichnis oder das Rootverzeichnis einstellbar.
Zum Vergrößern anklicken....

In FF_EnterFileName ist das jetzt schon möglich:

z.B.:
file = FF_EnterFileName(true, "C:\Daten\*.jpg)

Für FF_EnterPath wärs natürlich auch schön ;-)


Dein Script, auf den Minimalkern zusammengeschrumpft, funktioniert an 3 Stellen gleichzeitig nicht. Du kannst offensichtlich nichts für die Malesse. So wie es da steht, sollte es funktionieren. Vielleicht  übersehe ich etwas wegen müde, aber ich glaube eher, daß da wieder  mal ein Pointer auf einen Pointer auf ein Array von Pointern im Scriptbereich oder in FF sein Unwesen treibt. Der Fluch der Menschheit, ich werde nie begreifen, wie dieser Stroustrup-Unhold darauf verfallen ist, Programmierer als Precompiler zu mißbrauchen.
Zum Vergrößern anklicken....

Hallo Jochen,
ich denke, so es kann auch nicht funktionieren:

mit FF_CloseDialog wird der Dialog gelöscht, d.h. er ist nicht mehr ansprechbar. Das ist ja auch sinnvoll, weil man sich nicht dauernd mit Speicherleichen belasten möchte. Wenn du anschließend den Dialog änderst und mit ShowDialog die geschändete Leiche wieder aufrufst, bekommst du natürlich "merkwürdige" Effekte, oft geht es vielleicht noch. Eigentlich sollte aber eine Fehlermeldung kommen ala "Dialog existiert nicht".

Wenn das Codestück am Schleifenanfang den AddDialog enthält, dann läuft das Script auch ohne Probleme. Schön ist das natürlich nicht, besser wäre wie schon erwähnt ein RefreshDialog, frei nach dem Motto: "Mein Event muss ich mir schon selber anstoßen" ;-)

Gute Nacht Zaph
 
Meine Güte, könnt Ihr schwere Fehlermeldungen. Hätte nicht ein einfaches 'FF_SetControl() geht nicht bei EDIT' genügt?
 
Hallo, Zaph

war schon spät in der Nacht, oder ;)?

Solange die Schleife läuft, gibt es keinen Add, keinen Close, nichts. Sieh's Dir noch mal genau an. Es wird nur immer wieder ein Feld besetzt, ausgelesen und die Maske durch den Show "refresht"

Nachtrag: FF_EnterPath hat bereits jetzt einen BOOL für das FF-Verzeichnis.


@ Joachim

und den BOOL im FF_EnterPath nicht zu vergessen ...

PS. Was ist mit meiner Anfrage weiter oben? Gelesen?


@An alle Mitstreiter

können wir uns vielleicht mit dem Thread in den Script-Bereich verfügen? Ich kann eine gewisse Verstimmung schon verstehen, wenn unsere Forumskollegen von der künstlerisch darstellenden Fraktion erwartungsvoll bei Beta-Test reinsehen und dann Script-Code-Diskussionen vorfinden.

Gruß Jochen  
 
@Jochen:
Der Rest ist erledigt bzw. in Arbeit. Wobei mir die Eieruhr noch nicht aufgefallen ist ...
 
Hallo, Joachim

SetControl funktioniert.
EnterPath funktioniert.

Die Buttons im Bild verschwinden jetzt, wenn man in das Bild klickt. Kannst Du außerdem mal einen schwarzen Hintergrund wählen? Sieht aus, als wäre ein Loch in das Bild geschnitten, wo der Button durchkuckt. Wenn das Probleme macht, muß es auch so gehen, vielleicht kannst Du ja da noch etwas dran drehen.

Gruß Jochen
 
Warum lässt Du das Bild irgendwelche Buttons verdecken? Ist nicht so im Sinne des Erfinders ...
 
Das dachte ich mir schon :).

Wenn man von einem Bild eine Großdarstellung ohne zu scrollen haben möchte (dafür könnte man ja den Explorer anzapfen) und dafür extra eine Form aufmacht, gibt es bei Hochkantformat trotzdem nicht viel zu sehen. Wenn man jetzt noch die Buttons und einen angemessenen  Abstand abzieht, lohnt sich die Sache fast nicht mehr, also dann lieber die Buttons im Bild, damit kann man gut leben. (Außer Du baust eine FF-Funktion, mit der man die Buttons zeitweilig verschwinden lassen kann, aber das wäre dann wohl etwas zuviel verlangt).

Die zweite Möglichkeit ist, die ganze Form mit einem Hintergrundmuster zu hinterlegen. Meine Idee war, eine VB-Form aufzumachen, diese zuzukacheln, Screenshot, diesen passend schneiden und als Hintergrundbild auf die Form. Wenn es allerdings Probleme gibt mit den Buttons - auf dieses Feature könnte ich gerne verzichten.

Gruß Jochen
 
Build 84 enthält FF_ShowImage(), ein eigenständiges Fenster für das geladene Bild.
Ausserdem gibt's Druckersupport. Zur Veranschaulichung des Prinzips:

FF_SelectPrinter
FF_LoadImage FF_GetImageName(0)
pxs = FF_GetPrintablePixelX
pys = FF_GetPrintablePixelY
ixs = FF_GetImageWidth()
iys = FF_GetImageHeight()
xscal = pxs / ixs
yscal = pys / iys
if xscal < yscal then scal = xscal else scal = yscal end if
FF_StartPrintPage
FF_PrintImage 0,0,ixs*scal,iys*scal
FF_EndPrintPage


und schon bin ich weg, in Urlaub ...  8)
 
Hallo J.K.,

schließe mich Jochen an ;)

Habe aber schon Arbeit für die Rückkehr:

Habe herausgefunden warum meine Scriptings so lange Nachwehen haben und dann irgendein Bild in FF am Schluss laden.
Bitte Möglichkeit schaffen, die Option "Bild automatisch laden" auszulesen und zu ändern oder temporär während des Scriptings zu unterdrücken.

Vielen Dank im Voraus,

W.P.
 
Hallo J.K.,

bitte EditControl aufbohren. Momentan kann man nur 259 Zeichen mit GetControl und SetControl verarbeiten. Das ist zu wenig. Ein Test mit der Zwischenablage hat gezeigt, dass das Control mehr verarbeiten könnte...

Anregung:
Splitten des EDIT-Controls in EDIT und EDIT_MULTILINE. In EDIT_MULTILINE bei Bedarf Schieberegler eingeblendet.

In Zeiten von Win95 und höher, die Möglichkeiten bei den Controls, Rahmen ein- und auszuschalten (STATIC, EDIT). Sowie den Rahmen umzuschalten auf 3D oder einfach (liesse sich mit einer Funktion erschlagen). Um die Kompatibliltät zu waren, Vorbelegung wie jetzt.

Schönen Gruß,

W.P.
 
Hallo,

weil schon dabei:

Für einen Assistenten muss ich die Dialogknöpfe "OK" und "Abbrechen" entweder unsichtbar machen, löschen oder umbenennen können. Welche Methode angewandt wird, ist mir wurscht. Blöd schaut halt aus "Zurück", "Weiter", "OK", "Abbrechen" oder "Neues Projekt", "Projekt laden", "OK", "Abbrechen"
Ein "Übernehmen" von Parametern ist momentan auch nicht möglich, da die Standard-Buttons nicht verschoben werden können.

Auch nicht schlecht wäre ein Bild in den Button laden zu können und Ihn dann dafür größer zu zeichnen. Damit kann man leichter den Effekt eines Setups erzielen.

Damit einhergehen würde natürlich, dass man die Funktion "CANCEL" einem beliebigen Button vergeben kann, ebenso ein "DEFAULT" für die Standardschaltfläche.

Schönen Gruß,

W.P.
 
Hallo, Werner

Für OK und Cancel sollten ganz normale frei positionierbare Buttons verwendet werden können, die entweder ein zusätzliches Argument bekommen oder bei denen die Captions "OK" bzw. "Abbrechen" von Joachim ausgewertet werden. Dazu würden nicht einmal die derzeitigen Funktionsargumente geändert werden müssen. Ersteres wäre sicher besser.

Gruß Jochen
 
Hallo Jochen,

natürlich wäre dies das idealste. Nur gibt es dann Probleme mit der Kompatibilität. Scripte die bis zum neuen Release geschrieben wurden laufen dann nicht mehr. Lieber dann einen Schalter für den gesamten Dialog. Vielleicht könnte man dann auch ein normales Fenster daraus basteln? Drag&Drop in eine Listbox mit Bildern? Das wäre zuuu schön. ::) ::) 8)

Gruß,

Werner.
 
Hallo J.K,

Betrifft Dialoge:
SetControl geht im geöffneten Zustand nicht (obwohl Rückgabewert 'true' ist) bei:
COMBO, (BOOL ?)

Folgende Controls lassen sich gar nicht verändern:
STATIC, BUTTON, GROUP


Wichtig!
Wünschenswert wäre ein einheitliche Setzen/Lesen von Werten in allen Controls und im Dialog!
Als Event sollte dann der Control-Name oder beim Schließen über Dialogleiste, der Dialog selbst übergeben werden! Da nur ein Click-Ereignis übergeben wird, völlig ausreichend.
Hintergrund: Um den Aufbau auch komplizierterer Dialoge zu vereinfachen und unter Umständen auch eine Internationalisierung zu erreichen, erstelle ich gerade eine Klasse, die den kompletten Dialog aus einer Datei liest, ohne dass unbedingt absolute Werte angegeben werden müssen.
Bei jedem zweiten Control ist eine Fallunterscheidung nötig! Warum eigentlich? Müsste Doch auch einfacher in der Scripting-Maschine zu verwalten sein, wenn alle Controls dem gleichen Schema folgen! Nur das Zeichnen erfordert dann eine Fallunterscheidung, sofern kein Win-Standard-Control modifiziert wird.

Schönen Gruß,

W.P.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben