Skripting - Grundlagen und Allgemeines
- Ersteller opi-hs
- Erstellt am
hhoefling
Mitglied
Mecki14
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Nach dem Thema Versionsprüfung möchte ich hier mal aufzeigen, wie die Integration einer Kurzbeschreibung bzw. Hilfestellung aussehen könnte.
Der Zugriff zur Kurzbeschreibung könnte über einen ?- oder Info-Button ermöglicht werden.
Im einfachsten Fall wird damit eine MsgBox aufgerufen:
Das reicht in vielen Fällen aus, zumindest wenn die Meldung nicht mehr als ca. 1000 Zeichen hat. Lästig ist, dass bei mehrzeiligem Text jede Zeile in Anführungszeichen gesetzt und jeweils mit vbNewLine (entspricht chr(13) & chr(10)) abgeschlossen werden muss.
Die Beschränkung auf ca. 1000 Zeichen kann man umgehen durch Verwendung der PopUp-Methode:
Der Aufwand bei mehrzeiligem Text ist der gleiche wie bei der MsgBox.
Eine komfortablere Möglichkeit ist, die Kurzbeschreibung in eine Textdatei zu packen und diese bei Bedarf mit Hilfe des FileSystemObject auszulesen und in einem separaten Dialogfeld mit Textfeld anzuzeigen.
Eine meine Ansicht nach sehr geschickte Variante davon hat Heinrich in seinem Skript Imageselector angewendet. Er hat die Beschreibung statt in eine zusätzlichen Textdatei direkt in das Skript geschrieben und dort ausgelesen. Das sieht in etwa so aus:
Wenn jemand den Code zum Testen in den FFSkript-Editor kopiert, muss dieser vor dem Ausführen unbedingt unter dem Namen Test_Kurzbeschreibung.vbs abgespeichert werden.
"Last but not least" kann man eine externe Beschreibungsdatei anlegen und diese bei Aufruf mit der der Extension zugehörigen Standardanwendung öffnen. Dies könnte beispielsweise eine PDF-Datei sein, weil einerseits Freeware zur Verfügung steht, um eine PDF-Datei zu erzeugen (z.B. hier), andererseits auf jedem Rechner ein PDF-Reader installiert sein dürfte. Der Aufruf sieht wie folgt aus:
Die Datei Beispiel.PDF muss natürlich im FF-Skriptordner abgelegt sein. Pfad und Datei werden wegen eventueller Leerzeichen mit Anführungszeichen eingefasst. Auch dieser Code muss vor dem Testen abgespeichert werden, weil sonst FF_GetScriptPath nicht funktioniert.
Diese Methode hat den Vorteil, dass das Skript während der Anzeige der Beschreibung weiter läuft. Der Nachteil ist, dass die Anwendung, die die Beschreibung geöffnet hat, separat geschlossen werden muss.
Ich schließe mich Heinz an ??? ??? und mache einfach mal weiter.
Nach dem Thema Versionsprüfung möchte ich hier mal aufzeigen, wie die Integration einer Kurzbeschreibung bzw. Hilfestellung aussehen könnte.
Der Zugriff zur Kurzbeschreibung könnte über einen ?- oder Info-Button ermöglicht werden.
Im einfachsten Fall wird damit eine MsgBox aufgerufen:
Code:
MsgBox "Meldung",,"Titel"Die Beschränkung auf ca. 1000 Zeichen kann man umgehen durch Verwendung der PopUp-Methode:
Code:
Set WshShell = CreateObject("WScript.Shell")
WshShell.Popup "Meldung",,"Titel"Eine komfortablere Möglichkeit ist, die Kurzbeschreibung in eine Textdatei zu packen und diese bei Bedarf mit Hilfe des FileSystemObject auszulesen und in einem separaten Dialogfeld mit Textfeld anzuzeigen.
Eine meine Ansicht nach sehr geschickte Variante davon hat Heinrich in seinem Skript Imageselector angewendet. Er hat die Beschreibung statt in eine zusätzlichen Textdatei direkt in das Skript geschrieben und dort ausgelesen. Das sieht in etwa so aus:
Code:
'FFSubmenu=Test
'FFName=Kurzbeschreibung
'FFSkriptname=Test_Kurzbeschreibung.vbs
'** Start Kurzbeschreibung ********************************************
' Kurzbeschreibung
' ================
' Dies ist ein Beispiel für eine Kurzbeschreibung in einem FF-Skript. Dies
' ist ein Beispiel für eine Kurzbeschreibung in einem FF-Skript. Dies ist
' ein Beispiel für eine Kurzbeschreibung in einem FF-Skript. Dies ist ein
' Beispiel für eine Kurzbeschreibung in einem FF-Skript.
'
' Erläuterung
' -----------
' Die Beschreibung wird direkt in das Skript geschrieben und dann mit
' FileSytemObject dort ausgelesen. Das hat den Vorteil, dass der Text flüssig
' geschrieben werden kann und er auch direkt im Skript leicht lesbar ist.
' Außerdem kann er beliebig lang sein (fast beliebig lang).
'
' copyright xyz
'** Ende Kurzbeschreibung *********************************************
Option Explicit
Dim objFs, Kurzbeschreibung, KBvorhanden, LaengeMax
const SkriptName = "Test_Kurzbeschreibung.vbs" 'Skriptname
'nach Betätigung des Hilfebutton
call Main
'------------------------------------------------------------------------
Sub Main
if not KBvorhanden then call KurzbeschreibungLesen
if KBvorhanden then
call KurzbeschreibungAnzeigen
else
msgbox "Keine Kurzbeschreibung gefunden!",,"Meldung"
end if
End Sub
'------------------------------------------------------------------------
Sub KurzbeschreibungLesen
on error resume next
Const ForReading = 1
Dim Skript, Anfang, Ende, Zeile
Set objFS = CreateObject("Scripting.FileSystemObject") 'FileSystemObject
Set Skript = objFS.OpenTextFile(FF_GetScriptPath & "\" & SkriptName, ForReading, False)
if err.number = 53 then
msgbox "Wahrscheinlich wurde der Originalskriptname " & """" & SkriptName & """" & " abgeändert." & vbNewLine & _
"Die Kurzbeschreibung kann daher nicht angezeigt werden.",,"Meldung"
exit sub
end if
Do While Skript.AtEndOfStream <> True
Zeile = Skript.ReadLine
if instr(Zeile,"** Ende Kurzbeschreibung") > 0 then Ende = true
if Ende then exit do
if Anfang then Kurzbeschreibung = Kurzbeschreibung & mid(Zeile,2) & vbNewLine
if len(Zeile)-1 > LaengeMax then LaengeMax = len(Zeile)-1
if instr(Zeile,"** Start Kurzbeschreibung") > 0 then Anfang = true
Loop
if Anfang and Ende then KBvorhanden = true
Skript.Close
End Sub
'------------------------------------------------------------------------
Sub KurzbeschreibungAnzeigen
Dim Taste
Dim Breite : Breite = LaengeMax * 2.6 + 15
const Hoehe = 100
const ES_READONLY = 2048
const WS_VSCROLL = 2097152
FF_AddDialog "Kurzbeschreibung",Breite,Hoehe
FF_AddControl "Kurzbeschreibung","Beschreibung","EDIT",0,0,Breite,Hoehe-20
FF_SetControlStyle "Kurzbeschreibung","Beschreibung", ES_READONLY + WS_VSCROLL
FF_AddControl "Kurzbeschreibung","OK","BUTTON",Breite/2-15,Hoehe-15,30,10
FF_SetControl "Kurzbeschreibung","Beschreibung",Kurzbeschreibung
do
Taste = FF_ShowDialog("Kurzbeschreibung")
if Taste = "CANCEL" or Taste = "OK" then exit do
loop
call FF_CloseDialog("Kurzbeschreibung")
End Sub
'------------------------------------------------------------------------"Last but not least" kann man eine externe Beschreibungsdatei anlegen und diese bei Aufruf mit der der Extension zugehörigen Standardanwendung öffnen. Dies könnte beispielsweise eine PDF-Datei sein, weil einerseits Freeware zur Verfügung steht, um eine PDF-Datei zu erzeugen (z.B. hier), andererseits auf jedem Rechner ein PDF-Reader installiert sein dürfte. Der Aufruf sieht wie folgt aus:
Code:
Set WshShell = CreateObject("WScript.Shell")
Datei = """" & FF_GetScriptPath & "\Beispiel.pdf" & """"
WshShell.Run DateiDiese Methode hat den Vorteil, dass das Skript während der Anzeige der Beschreibung weiter läuft. Der Nachteil ist, dass die Anwendung, die die Beschreibung geöffnet hat, separat geschlossen werden muss.
Zuletzt bearbeitet:
AW: Skripting - Grundlagen und Allgemeines
Hallo,
nachdem ich auf meinen letzten Beitrag 22 ein vermehrtes ??? als Reaktion erhalten habe, vermute ich mal, das meine Bemerkung gänzlich missverstanden worden ist. Ich wollte damit weder irgendjemand aus dem Forum zu nahe treten (es läge auch überhaupt kein Grund dafür vor) noch irgendetwas provozieren. Es ging mir lediglich darum klarzustellen, dass ich nach mehreren Beiträgen in Folge dem Eindruck vorbeugen möchte, ich würde diesen Thread zur eigenen Selbstdarstellung benutzen. Dazu wollte ich lediglich betonen, dass das keineswegs meine Intention ist.
Gruß
Heinrich
Hallo,
nachdem ich auf meinen letzten Beitrag 22 ein vermehrtes ??? als Reaktion erhalten habe, vermute ich mal, das meine Bemerkung gänzlich missverstanden worden ist. Ich wollte damit weder irgendjemand aus dem Forum zu nahe treten (es läge auch überhaupt kein Grund dafür vor) noch irgendetwas provozieren. Es ging mir lediglich darum klarzustellen, dass ich nach mehreren Beiträgen in Folge dem Eindruck vorbeugen möchte, ich würde diesen Thread zur eigenen Selbstdarstellung benutzen. Dazu wollte ich lediglich betonen, dass das keineswegs meine Intention ist.
Gruß
Heinrich
Mecki14
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Alles klar Heinrich
Ich möchte noch einen kleine Nachtrag zur Kurzbeschreibung liefern:
Die Methode, die Beschreibung direkt in das Skript zu schreiben und dort auszulesen, lässt sich bei Beschreibungen mittleren Umfangs sehr gut mit der PopUp-Methode kombinieren.
Die Feststellung der längsten Zeile in der Sub KurzbeschreibungLesen ist dann überflüssig und die Sub KurzbeschreibungAnzeigen entfällt ganz. Der Aufruf call KurzbeschreibungLesen wird ersetzt durch
Oben bei den Variablen muss noch Dim WshShell eingetragen werden und fertig.
Alles klar Heinrich
Ich möchte noch einen kleine Nachtrag zur Kurzbeschreibung liefern:
Die Methode, die Beschreibung direkt in das Skript zu schreiben und dort auszulesen, lässt sich bei Beschreibungen mittleren Umfangs sehr gut mit der PopUp-Methode kombinieren.
Die Feststellung der längsten Zeile in der Sub KurzbeschreibungLesen ist dann überflüssig und die Sub KurzbeschreibungAnzeigen entfällt ganz. Der Aufruf call KurzbeschreibungLesen wird ersetzt durch
Code:
Set WshShell = CreateObject("WScript.Shell")
WshShell.Popup Kurzbeschreibung,,"Titel"AW: Skripting - Grundlagen und Allgemeines
Hallo, zum Thema DialogUnits:
im Zusammenhang mit der Entwicklung des Skriptes "ImageSelector" ergab sich das Problem, eine an die jeweilige Monitorauflösung angepasste Dialogdarstellung zu finden. Vor allem war für die Dimensionierung und Placierung der verschiedenen Dialogelemente wichtig zu wissen, in welchen Einheiten ist der aktuelle Anwenderbildschirm aufgeteilt. Die ursprüngliche Annahme, dass die Dialogeinheiten sich aus der Bildschirmauflösung einfach durch Division durch 2, also:
x-Units = ScreenWidth/2 und
y-Units = ScreenHeight/2
ist grundsätzlich nicht koorekt, auch wenn es meistens hinhaut.
Eine Klarstellung von JKS hat jedoch eine andere präzisere Berechnunggrundlage aufgezeigt, die inzwischen im ImageSelector integriert wurde. Im Rahmen einer aufrufbaren Subroutine empfiehlt sich in VBS der folgende Lösungsvorschlag:
In JS könnte das ganze dann wie folgt aussehen. Anmerkung: Da in JS bei den Parametern für den Funktions-/Prozedur-Aufruf leider keine Referenzparameter möglich sind, wurde hier die Rückgabe der Dialog-Units in einem 2-elementigen Array realisiert:
Viel Spaß (und Erkenntnis) beim Ermiiteln eurer DialogUnits.
Gruß
Heinrich
Hallo, zum Thema DialogUnits:
im Zusammenhang mit der Entwicklung des Skriptes "ImageSelector" ergab sich das Problem, eine an die jeweilige Monitorauflösung angepasste Dialogdarstellung zu finden. Vor allem war für die Dimensionierung und Placierung der verschiedenen Dialogelemente wichtig zu wissen, in welchen Einheiten ist der aktuelle Anwenderbildschirm aufgeteilt. Die ursprüngliche Annahme, dass die Dialogeinheiten sich aus der Bildschirmauflösung einfach durch Division durch 2, also:
x-Units = ScreenWidth/2 und
y-Units = ScreenHeight/2
ist grundsätzlich nicht koorekt, auch wenn es meistens hinhaut.
Eine Klarstellung von JKS hat jedoch eine andere präzisere Berechnunggrundlage aufgezeigt, die inzwischen im ImageSelector integriert wurde. Im Rahmen einer aufrufbaren Subroutine empfiehlt sich in VBS der folgende Lösungsvorschlag:
Code:
dim g_XUnits,g_YUnits
sub get_dialogunits(byRef p_XUnits,byRef p_YUnits)
const SM_CXSCREEN=0
const SM_CYSCREEN=1
p_XUnits=FF_GetSystemMetrics(SM_CXSCREEN)*4\(CDbl(FF_GetDialogBaseUnits) Mod &h10000&)
p_YUnits=FF_GetSystemMetrics(SM_CYSCREEN)*8\(CDbl(FF_GetDialogBaseUnits) \ &h10000&)
end sub
[I]'Mit dem Aufruf der Subroutine erhält man in den Übergabeparametern die gewünschten Daten,
'die dann - wie hier gezeigt - ausgegeben werden können.[/I]
call get_dialogunits(g_XUnits,g_YUnits)
call FF_MessageBox(g_XUnits & "," & g_YUnits,0)In JS könnte das ganze dann wie folgt aussehen. Anmerkung: Da in JS bei den Parametern für den Funktions-/Prozedur-Aufruf leider keine Referenzparameter möglich sind, wurde hier die Rückgabe der Dialog-Units in einem 2-elementigen Array realisiert:
Code:
function Units()
{var SM_CXSCREEN=0,SM_CYSCREEN=1
return(new Array(Math.floor(4*FF_GetSystemMetrics(SM_CXSCREEN) / (FF_GetDialogBaseUnits % 0x10000)),
Math.floor(8*FF_GetSystemMetrics(SM_CYSCREEN) / Math.floor(FF_GetDialogBaseUnits / 0x10000))))
}
// Mit folgendem Aufruf lassen sich die ermittelten Units ausgeben:
FF_MessageBox(Units(),0)Viel Spaß (und Erkenntnis) beim Ermiiteln eurer DialogUnits.
Gruß
Heinrich
Zuletzt bearbeitet:
Mecki14
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Hallo Heinrich,
hier hatte ich schon mal auf diesen Umstand hingewiesen, aber ich hatte auch keine vernünftige Lösung für das Problem. Die jetzt von Dir vorgeschlagene Funktion gehört unbedingt ins Wissensrepertoire für alle Skriptschreiber, die den ganzen Bildschirm nutzen wollen.
Hallo Heinrich,
hier hatte ich schon mal auf diesen Umstand hingewiesen, aber ich hatte auch keine vernünftige Lösung für das Problem. Die jetzt von Dir vorgeschlagene Funktion gehört unbedingt ins Wissensrepertoire für alle Skriptschreiber, die den ganzen Bildschirm nutzen wollen.
AW: Skripting - Grundlagen und Allgemeines
Hallo in die Runde der Skripting-Fans.
Diesmal will ich mal mit einem ganz abenteuerlichen Thema kommen:
Im Zusammenhang mit dem an das Skript ImageSelector herangetragen Wunsch, die Hintergrundfarbe der Dialogboxen zu modifizieren habe ich mich mal etwas näher mit diesem Thema beschäftigt.
Nach meiner unmaßgeblicher Ansicht ist es ja wohl so, dass die in FF integrierte Skriptingmaschine eine Vielzahl der FF-spezifischen FF_-Befehle mehr oder weniger direkt an die WinAPI weitergibt; in dieser Art sicher auch die Dialog-Steuerung und -Gestaltung. Dies bedeuted, dass kein Einfluss auf die Farb-(und wahrscheinlich auch nicht Schrift-)Gestaltung genommen wird, sondern dies der Default-Einstellung der WinAPI überlassen bleibt. Und damit ergibt sich für den Entwickler von FF-Skripts einschl. allgemeiner sonstiger Skripts keine Möglichkeit, auf die Gestaltung der Dialogboxen Einfluss zu nehmen.
In der [B]Systemsteuerung[/B] (unter Windows XP) gibt es allerdings unter "[B]Anzeige[/B]", "[B]Darstellung[/B]", "[B]Erweitert[/B]" den Zugang zur Gestaltung der Dialogfelder. Doch ... und das ist leider die Krux, gibt es dort keine Möglichkeit der individuellen Farbgestaltung für die Hintergrundfarbe.
Aber keine Regel ohne Ausnahme: in der Registry gibt es unter "HKEY_CURRENT_USER\Control Panel\Colors" einen Key namens "ButtonFace", der genau diese Hintergrundfarbe in der Form Rot Grün Blau festlegt. Der dort abgelegte Standardwert beträgt "236 233 216", ein leicht gelb-beige angehauchtes Grau. Was soll einen nun - abgesehen von der allgemeinen Vorsicht im Umgang mit der Registry - daran hindern, hier seine Lieblingsfarbe zu definieren?
Dabei würde "255 255 255" Weiß bedeuten und "0 0 0" das absolute Schwarz (siehe Thread 11643). Doch diesen Wert sollte man - wie alle sehr dunklen Farben - unbeduíngt vermeiden, weil sonst die in Schwarz dargestellten textlichen Inhalte aus Mangel an Kontrast nicht mehr zu erkennen sind.
Aber so einfach läuft es mit der Farbänderung nicht. Sie wird erst nach(!) dem nächsten Booten des Rechners aktiviert.
Ich habe aus diesem Grunde ein wenig mit den Skripting herumgespielt und mal eine Lösung ins Auge gefasst, die zwar einen gewissen Automatismus erlaubt aber ansonsten recht abenteuerlich ist:
Im ImageSelector (Version 3.4) wird jetzt beim Start die Option zum Ändern der Hintergrundfarbe für Dialogboxen angeboten. Hat man eine Farbe gewählt, wird automatisch ein Reboot des Systems eingeleitet. Es wird zwar kein kompletter Neustart des Windows-System vorgenommen, aber der aktuell angemeldete Benutzer (User) wird abgemeldet. Unmittelbar danach ist die Benutzeranmeldung wieder vorzunehmen und das System startet jetzt mit der neuen Dialogbox-Farbe. Wobei der unmittelbare Aufruf von FF zusammen mit dem Skript ImageSelector direkt integriert ist, denn den wollte man ja - allerdings mit geänderter Hintergrundfarbe - ausführen. Beim Programmende wird abgefragt, ob auf die ursprüngliche Dialogfarbe zurückgesetzt werden soll, was zutreffendenfalls natürlich auch wieder nur über Benutzerab- und -anmeldung ablaufen muss; dafür aber weitestgehend automatisch.
Ein fürwahr abenteuerliches Konstrukt und ich würde mich über eine Belehrung, wie die Hintergrundfarbe der Dialogboxen ohne einen solchen programmtechnischen Umweg per Skript geändert/eingestellt werden kann, sehr freuen. Ansonsten ist es mal ein netter Versuch, was sich mit Hilfe von simplen Skripts so alles machen lässt. Vielleicht kann der eine oder andere es als Anregung nutzen oder weiterentwickeln.
Gruß
Heinrich
Hallo in die Runde der Skripting-Fans.
Diesmal will ich mal mit einem ganz abenteuerlichen Thema kommen:
Im Zusammenhang mit dem an das Skript ImageSelector herangetragen Wunsch, die Hintergrundfarbe der Dialogboxen zu modifizieren habe ich mich mal etwas näher mit diesem Thema beschäftigt.
Nach meiner unmaßgeblicher Ansicht ist es ja wohl so, dass die in FF integrierte Skriptingmaschine eine Vielzahl der FF-spezifischen FF_-Befehle mehr oder weniger direkt an die WinAPI weitergibt; in dieser Art sicher auch die Dialog-Steuerung und -Gestaltung. Dies bedeuted, dass kein Einfluss auf die Farb-(und wahrscheinlich auch nicht Schrift-)Gestaltung genommen wird, sondern dies der Default-Einstellung der WinAPI überlassen bleibt. Und damit ergibt sich für den Entwickler von FF-Skripts einschl. allgemeiner sonstiger Skripts keine Möglichkeit, auf die Gestaltung der Dialogboxen Einfluss zu nehmen.
In der [B]Systemsteuerung[/B] (unter Windows XP) gibt es allerdings unter "[B]Anzeige[/B]", "[B]Darstellung[/B]", "[B]Erweitert[/B]" den Zugang zur Gestaltung der Dialogfelder. Doch ... und das ist leider die Krux, gibt es dort keine Möglichkeit der individuellen Farbgestaltung für die Hintergrundfarbe.
Aber keine Regel ohne Ausnahme: in der Registry gibt es unter "HKEY_CURRENT_USER\Control Panel\Colors" einen Key namens "ButtonFace", der genau diese Hintergrundfarbe in der Form Rot Grün Blau festlegt. Der dort abgelegte Standardwert beträgt "236 233 216", ein leicht gelb-beige angehauchtes Grau. Was soll einen nun - abgesehen von der allgemeinen Vorsicht im Umgang mit der Registry - daran hindern, hier seine Lieblingsfarbe zu definieren?
Dabei würde "255 255 255" Weiß bedeuten und "0 0 0" das absolute Schwarz (siehe Thread 11643). Doch diesen Wert sollte man - wie alle sehr dunklen Farben - unbeduíngt vermeiden, weil sonst die in Schwarz dargestellten textlichen Inhalte aus Mangel an Kontrast nicht mehr zu erkennen sind.
Aber so einfach läuft es mit der Farbänderung nicht. Sie wird erst nach(!) dem nächsten Booten des Rechners aktiviert.
Ich habe aus diesem Grunde ein wenig mit den Skripting herumgespielt und mal eine Lösung ins Auge gefasst, die zwar einen gewissen Automatismus erlaubt aber ansonsten recht abenteuerlich ist:
Im ImageSelector (Version 3.4) wird jetzt beim Start die Option zum Ändern der Hintergrundfarbe für Dialogboxen angeboten. Hat man eine Farbe gewählt, wird automatisch ein Reboot des Systems eingeleitet. Es wird zwar kein kompletter Neustart des Windows-System vorgenommen, aber der aktuell angemeldete Benutzer (User) wird abgemeldet. Unmittelbar danach ist die Benutzeranmeldung wieder vorzunehmen und das System startet jetzt mit der neuen Dialogbox-Farbe. Wobei der unmittelbare Aufruf von FF zusammen mit dem Skript ImageSelector direkt integriert ist, denn den wollte man ja - allerdings mit geänderter Hintergrundfarbe - ausführen. Beim Programmende wird abgefragt, ob auf die ursprüngliche Dialogfarbe zurückgesetzt werden soll, was zutreffendenfalls natürlich auch wieder nur über Benutzerab- und -anmeldung ablaufen muss; dafür aber weitestgehend automatisch.
Ein fürwahr abenteuerliches Konstrukt und ich würde mich über eine Belehrung, wie die Hintergrundfarbe der Dialogboxen ohne einen solchen programmtechnischen Umweg per Skript geändert/eingestellt werden kann, sehr freuen. Ansonsten ist es mal ein netter Versuch, was sich mit Hilfe von simplen Skripts so alles machen lässt. Vielleicht kann der eine oder andere es als Anregung nutzen oder weiterentwickeln.
Gruß
Heinrich
Zuletzt bearbeitet:
hhoefling
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Das währe mir zu Abenteuerlich.... lass die Finger davon.
Programme die so etwas tun, fliegen bei mir sofort wieder runter.
Beispiel:
- Stell dir vor, während ich im Script bin, somit die geänderten Farben aktiv sind, klingelt mein ISDN Telefon und die ISDN-Software will mir die Rufnummer einblenden (ja, es gibt außer FF noch andere Programme
) und nun kann ich wegen der Farbeinstellung die Telefonnummer nicht mehr lesen....
Ich Fluche genau einmal, dann ist das Programm deinstalliert.
Das währe mir zu Abenteuerlich.... lass die Finger davon.
Programme die so etwas tun, fliegen bei mir sofort wieder runter.
Beispiel:
- Stell dir vor, während ich im Script bin, somit die geänderten Farben aktiv sind, klingelt mein ISDN Telefon und die ISDN-Software will mir die Rufnummer einblenden (ja, es gibt außer FF noch andere Programme
) und nun kann ich wegen der Farbeinstellung die Telefonnummer nicht mehr lesen....Ich Fluche genau einmal, dann ist das Programm deinstalliert.
AW: Skripting - Grundlagen und Allgemeines
Hallo Heinz,
das ist schon klar!
Vor allem sollten Anwender, die dazu neigen, sich Hintergrundfarben einzustellen, die sowohl in FF-Skripts als auch in ISDN-Software oder allen anderen mit Dialogen arbeitenden Programmen unlesbare Farbkombinationen ergeben, unbedingt die Finger von solchen Optionen lassen.
Heinrich
Hallo Heinz,
das ist schon klar!
Vor allem sollten Anwender, die dazu neigen, sich Hintergrundfarben einzustellen, die sowohl in FF-Skripts als auch in ISDN-Software oder allen anderen mit Dialogen arbeitenden Programmen unlesbare Farbkombinationen ergeben, unbedingt die Finger von solchen Optionen lassen.
Heinrich
wolboe
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Hallo,
habe die Farbänderung gestern probiert - aus reiner Neugier - und war leicht schockiert, als mir zwangsweise die Kontrolle entzogen wurde - aber nicht nur das: ich nutze zwei Monitore mit unterschiedlichen Hintergrundbildern - die waren vertauscht - zum Glück nur vertauscht - sonst kein Schaden weiter.
"Abenteuerlich" ist schon richtig eingestuft.
Gruß
Wolfgang
Hallo,
habe die Farbänderung gestern probiert - aus reiner Neugier - und war leicht schockiert, als mir zwangsweise die Kontrolle entzogen wurde - aber nicht nur das: ich nutze zwei Monitore mit unterschiedlichen Hintergrundbildern - die waren vertauscht - zum Glück nur vertauscht - sonst kein Schaden weiter.
"Abenteuerlich" ist schon richtig eingestuft.
Gruß
Wolfgang
AW: Skripting - Grundlagen und Allgemeines
Hallo Wolfgang,
Gruß
Heinrich
Hallo Wolfgang,
Das hatte ich aber im Beitrag erwähnt, dass fürs Neubooten des Systems zwecks Übernahme der in der Registry abgelegten "ButtonFace"-Farbe eine zwangsweise Benutzerab- und -anmeldung vorgenommen wird. Und solnge der "alte" Benutzer abgemeldet und der "neue" noch nicht angemeldet ist, gibt es eben in WINDOWS keinen aktiven Benutzer, folglich auch keine Kontrolle. Es ist mir klar, dass das ganze nicht viel mehr als eine (nette) Spielerei ist, die auch nur für den- oder diejenigen angedacht ist, der/die mit der WINDOWS-Standard-Farb-Einstellung nicht glücklich ist/sind.
Kann es sein, dass bei der Benutzerneuanmeldung eine Vertauschung erfolgte?
Gruß
Heinrich
wolboe
Mitglied
AW: Skripting - Grundlagen und Allgemeines
Hallo Heinrich,
ich "nutze" allein - diese Vertauschung war auch leicht zu ändern - habe nicht länger nach Ursachen gesucht.
Werde vorerst die Farbe nicht mehr ändern - wie schon gesagt - war ja reine Neugier, mit der Option zu spielen.
Gruß
Wolfgang
Hallo Heinrich,
ich "nutze" allein - diese Vertauschung war auch leicht zu ändern - habe nicht länger nach Ursachen gesucht.
Werde vorerst die Farbe nicht mehr ändern - wie schon gesagt - war ja reine Neugier, mit der Option zu spielen.
Gruß
Wolfgang
AW: Skripting - Grundlagen und Allgemeines
Weiteres zum Thema Skripting und darin eingebettete Dialoge: "Scheinbare Merkwürdigkeiten"
Wie bereits im Zusammenhang mit der Ankündigung zur letzten Version (3.5)
(siehe dortigen Beitrag 198) des ImageSelectors angedeutet, möchte ich mal die Gelegenheit nutzen, ein paar Anmerkungen zu genannten Thema machen.
Bei der Definition von Dialogen innerhalb eines Skriptings wird mit der Funktion FF_AddDialog("Dialogname", Weite, Höhe) ein Dialogfenster namens "Dialogname" in der Größe Weite x Höhe festgelegt, wobei die Dimensionierung für Weite und Höhe in sogenannten DialogUnits vorzunehmen ist (siehe hierzu einige Beiträge weiter oben). In dieses Dialogfenster können nun verschiedene Dialogelemente (Buttons etc. , wie im Beitrag von Mecki14:
Anleitung für FixFotos Skript-Dialogeditorl bestens beschrieben) in Art, Größe und Position definiert werden.
Was der grundlegenden Definition des Ausgangs-Dialogfensters (leider?) fehlt, ist die Festlegung, an welcher Stelle auf dem Bildschirm diese Fenster positioniert werden soll. Nach meinen Beobachtungen erfolgt diese Positionierung immer in der Mitte des zuletzt aktiven Fensters - vorausgesetzt es bleibt damit zur Gänze auf dem Bildschirm sichtbar. Dieses Dialogfenster ist nicht fixiert; es lässt sich - wie bei Windows üblich - mit der LMT in der oberen Titelleiste "anpacken" und verschieben aber nicht in der Größe ändern; die ist ja mit Weite und Höhe festgelegt.
Wie ist das nun mit der anzugebenden Weite und Höhe eines Dialogfensters, wenn es den gesamten Bildschirm ausfüllen soll? Für die Weite deckt sich dies mit der in DialogUnits per FF_GetSystemMetrics abrufbaren Bildschirmbreite. Für die Höhe muss man allerdings berücksichtigen, dass das mit FF_AddDialog(..., ..., Höhe) für Höhe angegebene Maß die innere Abmessung des Dialogfensters bestimmt, d.h. ohne die Höhe der immer zusätzlich dargestellten Titelleiste (title bar). Die Dicke (Höhe) dieser Titelleiste ist über Systemsteuerung, Anzeige, Darstellung, Erweitert, aktives Fenster ("Titelleiste des aktiven Fensters") festgelegt und kann - wenn gewünscht - dort auch geändert werden. Will mann also ein "Vollbild"-Dialogfenster festlegen, so muss man von der in DialogUnits per FF_GetSystemMetrics abrufbaren Bildschirmhöhe die Höhe der Titelleiste abziehen und die so erhaltenen Differenz als Höhe-Parameter an FF_AddDialog übergeben. Bedauerlicherweise lässt sich diese Größe, die auch noch in Pixelmaß der Bildschirmauflösung angegeben ist, nicht so ohne weiteres aus der Windows-Registry abfragen. Will man sich nicht auf Spekulation über die Höhe der Titelleiste beschränhken, was u.U. dazu führen kann, dass der "Vollbild"-Dialog nicht - wie gewünscht - korrekt dargestellt wird, muss man auf die Ermittlung dieses Maßes durch den FF-Skript-Aufruf: FF_GetSystemMetrics(SM_CYCAPTION) zurückgreifen. Wie das geht sei in dem folgenden Scripting-Code-Beispiel (für VBS) dargestellt. Die JS-Befehlsfolge kann sicher einfach anhand dem weiter oben in diesem Thread angeführten Beispiel zur Ermittlung Bildschirmgröße abgeleitet werden.
Mit dem Aufruf der Funktion erhält man die Höhe der Titelleiste (Title Bar) direkt umgerechnet (und ggf. aufgerundet) in DialogUnits; mit msgbox("Höhe der Titelleiste=" & titlebarheight) bekommt man zur Kontrolle den Wert angezeigt.
Unabhängig von diesen Besonderheiten wird die Darstellung des "Vollbild"-Dialoges noch beeinflusst durch die individuell eingestellten Taskleiten-Eigenschaften. Meine Empfehlung für die optimale Darstellung von "Vollbild"-Dialogen ist es von den vielfältigen Möglichkeiten, die sich aus:
Eine weitere Besonderheit im Zusammenhang mit der Definition von Dialogen innerhalb von Skripten ist bei der Definition von Dialogelementen vom Typus IMAGE zu beachten. Wie im ImageSelector ja anschaulich demonstriert lassen sich innerhalb eines Dialogfensters (beispielsweise "4er-Ansicht" oder "Thumb-Ansicht" zum Rückladen entfernter Bilder) ja eine beliebige Anzahl von Unterdialogfenster" mit FF_AddControl("Dialogname", "lfd. Elementname", IMAGE, lfd-x-Position, lfd-y-Position, Bildweite, Bildhöhe) definieren. Mit FF_SetControl("Dialogname", "lfd. Elementname", "lfd. Bildname") wird erreicht, dass das Image mit dem Pfad "lfd. Bildname" im betreffenden Dialogelementfenster wiedergegeben wird. Anstelle der Pfadangabe kann auch mit 0 das gerade geladene Bild aus dem Speicher oder mit 1, 2 usw. von den entsprechenden Stackpositionen geladen werden.
Aber Achtung!
In die entsprechenden Dialogelemente werden mit FF_SetControl nicht schon direkt die Bilder hineingeladen und dann mit FF_ShowDialog zur Anzeige auf dem Bildschirm gebracht! In die Dialogelemente werden mit FF_SetControl zunächst nur die Bildpfade bzw. Stackpositionen abgespeichert; die dazugehörenden Images werden dann erst mit FF_ShowDialog geladen und angezeigt. Dies bedeutet, innerhalb eines Loops können beispielsweise nicht nacheinander die darzustellenden Fotos mit FF_LoadImage(...) oder FF_LoadThumb(...) und mit FF_SetControl(..., ..., IMAGE, 0) vorbereitend zur Anzeige gebracht werden. In jedem Dialogelement wird lediglich als Bildquelle die "0" abgelegt, was dazu führt, dass mit FF_ShowDialog(...) in allen Image-Elementen das gleiche - eben das zuletzt geladene - Image geladen und abgebildet wird.
Gruß
Heinrich
Weiteres zum Thema Skripting und darin eingebettete Dialoge: "Scheinbare Merkwürdigkeiten"
Wie bereits im Zusammenhang mit der Ankündigung zur letzten Version (3.5)
(siehe dortigen Beitrag 198) des ImageSelectors angedeutet, möchte ich mal die Gelegenheit nutzen, ein paar Anmerkungen zu genannten Thema machen.
Bei der Definition von Dialogen innerhalb eines Skriptings wird mit der Funktion FF_AddDialog("Dialogname", Weite, Höhe) ein Dialogfenster namens "Dialogname" in der Größe Weite x Höhe festgelegt, wobei die Dimensionierung für Weite und Höhe in sogenannten DialogUnits vorzunehmen ist (siehe hierzu einige Beiträge weiter oben). In dieses Dialogfenster können nun verschiedene Dialogelemente (Buttons etc. , wie im Beitrag von Mecki14:
Anleitung für FixFotos Skript-Dialogeditorl bestens beschrieben) in Art, Größe und Position definiert werden.
Was der grundlegenden Definition des Ausgangs-Dialogfensters (leider?) fehlt, ist die Festlegung, an welcher Stelle auf dem Bildschirm diese Fenster positioniert werden soll. Nach meinen Beobachtungen erfolgt diese Positionierung immer in der Mitte des zuletzt aktiven Fensters - vorausgesetzt es bleibt damit zur Gänze auf dem Bildschirm sichtbar. Dieses Dialogfenster ist nicht fixiert; es lässt sich - wie bei Windows üblich - mit der LMT in der oberen Titelleiste "anpacken" und verschieben aber nicht in der Größe ändern; die ist ja mit Weite und Höhe festgelegt.
Wie ist das nun mit der anzugebenden Weite und Höhe eines Dialogfensters, wenn es den gesamten Bildschirm ausfüllen soll? Für die Weite deckt sich dies mit der in DialogUnits per FF_GetSystemMetrics abrufbaren Bildschirmbreite. Für die Höhe muss man allerdings berücksichtigen, dass das mit FF_AddDialog(..., ..., Höhe) für Höhe angegebene Maß die innere Abmessung des Dialogfensters bestimmt, d.h. ohne die Höhe der immer zusätzlich dargestellten Titelleiste (title bar). Die Dicke (Höhe) dieser Titelleiste ist über Systemsteuerung, Anzeige, Darstellung, Erweitert, aktives Fenster ("Titelleiste des aktiven Fensters") festgelegt und kann - wenn gewünscht - dort auch geändert werden. Will mann also ein "Vollbild"-Dialogfenster festlegen, so muss man von der in DialogUnits per FF_GetSystemMetrics abrufbaren Bildschirmhöhe die Höhe der Titelleiste abziehen und die so erhaltenen Differenz als Höhe-Parameter an FF_AddDialog übergeben. Bedauerlicherweise lässt sich diese Größe, die auch noch in Pixelmaß der Bildschirmauflösung angegeben ist, nicht so ohne weiteres aus der Windows-Registry abfragen. Will man sich nicht auf Spekulation über die Höhe der Titelleiste beschränhken, was u.U. dazu führen kann, dass der "Vollbild"-Dialog nicht - wie gewünscht - korrekt dargestellt wird, muss man auf die Ermittlung dieses Maßes durch den FF-Skript-Aufruf: FF_GetSystemMetrics(SM_CYCAPTION) zurückgreifen. Wie das geht sei in dem folgenden Scripting-Code-Beispiel (für VBS) dargestellt. Die JS-Befehlsfolge kann sicher einfach anhand dem weiter oben in diesem Thread angeführten Beispiel zur Ermittlung Bildschirmgröße abgeleitet werden.
Code:
function titlebarheight
const SM_CYCAPTION=4
titlebarheight=round((FF_GetSystemMetrics(SM_CYCAPTION)*8) / (CDbl(FF_GetDialogBaseUnits) \ &h10000&))
end functionMit dem Aufruf der Funktion erhält man die Höhe der Titelleiste (Title Bar) direkt umgerechnet (und ggf. aufgerundet) in DialogUnits; mit msgbox("Höhe der Titelleiste=" & titlebarheight) bekommt man zur Kontrolle den Wert angezeigt.
Unabhängig von diesen Besonderheiten wird die Darstellung des "Vollbild"-Dialoges noch beeinflusst durch die individuell eingestellten Taskleiten-Eigenschaften. Meine Empfehlung für die optimale Darstellung von "Vollbild"-Dialogen ist es von den vielfältigen Möglichkeiten, die sich aus:
- Taskleiste fixieren
- Taskleiste automatisch ausblenden
- Taskleiste immer im Vordergrund halten
Eine weitere Besonderheit im Zusammenhang mit der Definition von Dialogen innerhalb von Skripten ist bei der Definition von Dialogelementen vom Typus IMAGE zu beachten. Wie im ImageSelector ja anschaulich demonstriert lassen sich innerhalb eines Dialogfensters (beispielsweise "4er-Ansicht" oder "Thumb-Ansicht" zum Rückladen entfernter Bilder) ja eine beliebige Anzahl von Unterdialogfenster" mit FF_AddControl("Dialogname", "lfd. Elementname", IMAGE, lfd-x-Position, lfd-y-Position, Bildweite, Bildhöhe) definieren. Mit FF_SetControl("Dialogname", "lfd. Elementname", "lfd. Bildname") wird erreicht, dass das Image mit dem Pfad "lfd. Bildname" im betreffenden Dialogelementfenster wiedergegeben wird. Anstelle der Pfadangabe kann auch mit 0 das gerade geladene Bild aus dem Speicher oder mit 1, 2 usw. von den entsprechenden Stackpositionen geladen werden.
Aber Achtung!
In die entsprechenden Dialogelemente werden mit FF_SetControl nicht schon direkt die Bilder hineingeladen und dann mit FF_ShowDialog zur Anzeige auf dem Bildschirm gebracht! In die Dialogelemente werden mit FF_SetControl zunächst nur die Bildpfade bzw. Stackpositionen abgespeichert; die dazugehörenden Images werden dann erst mit FF_ShowDialog geladen und angezeigt. Dies bedeutet, innerhalb eines Loops können beispielsweise nicht nacheinander die darzustellenden Fotos mit FF_LoadImage(...) oder FF_LoadThumb(...) und mit FF_SetControl(..., ..., IMAGE, 0) vorbereitend zur Anzeige gebracht werden. In jedem Dialogelement wird lediglich als Bildquelle die "0" abgelegt, was dazu führt, dass mit FF_ShowDialog(...) in allen Image-Elementen das gleiche - eben das zuletzt geladene - Image geladen und abgebildet wird.
Gruß
Heinrich
AW: Skripting - Grundlagen und Allgemeines
Hallo Heinrich,
bzgl. letzte Angelegenheit. Hier kannst Du FF_PushImage und FF_PopImage verwenden. FF_SwapImage tauscht Bild "0" mit Bild "1". Der Stack ist, glaube ich 10 Bilder tief. Kann mich aber auch täuschen. Nutze dieses Feature fast nie.
Hallo Heinrich,
bzgl. letzte Angelegenheit. Hier kannst Du FF_PushImage und FF_PopImage verwenden. FF_SwapImage tauscht Bild "0" mit Bild "1". Der Stack ist, glaube ich 10 Bilder tief. Kann mich aber auch täuschen. Nutze dieses Feature fast nie.
AW: Skripting - Grundlagen und Allgemeines
Hallo Werner,
die "Speicherstelle", von der ein Image geladen werden soll, ist nicht das Problem. Egal ob man ein Bild von Position 0 (= unmittelbarer Arbeitsspeicher) oder irgendeiner Position (1, 2 ... usw.) vom Stack holt oder vorher durch FF_PopImage auf Position 1 und dann mit FF_SwapImage gegen das im Arbeitsspeicher tauscht oder durch ein weiteres FF_PopImage ganz in den Arbeitsspeicher bringt, spielt für die eigentliche Abbildung im Dialogelement vom Typ IMAGE keine Rolle.
Der Hintergedanke war, dass bei einer Vielzahl von Images (Thumbs) in einem Dialog aus Timinggründen sinnvollerweise nicht die kompletten Images mit ihrer hohen Pixelzahl geladen und dann entsprechend auf das Thumbmaß heruntergerechnet werden sollten, sondern mit FF_LoadThumb direkt die Vorschaubild in den Speicher und von da aus in das IMAGE-Element transferiert werden sollten.
Aber das geht so einfach leider nicht. Bei IMAGE-Elementen werden anders als bei BUTTON-, STATIC- oder sonstigen Elemente nicht die Bildinhalte schon mit FF_SetControl dorthinein transferriert, sondern nur die Zeiger oder Pfade auf die jeweiligen Images. Erst bei der Ausführung von FF_ShowDialog werden die Bildinhalte für die IMAGE-Fenster über die jeweils hinterlegten Pfad- bzw. Zeigerangaben geholt und dargestellt.
Einzige - aber m.E. unpraktische - Lösung wäre, jedes Thumb-Image mit FF_LoadThumb in den Arbeitsspeicher zu laden, mit FF_PushImage auf den Stack zu puschen und in den IMAGE-Elementen mit FF_SetControl die jeweils richtige Stackposition (n-1, n-2, ..., 1, 0) zu hinterlegen. Dann könnte mit FF_ShowImage das jeweilige Thumb-Image aus der richtigen Speicherposition in das entsprechende IMAGE-Fenster geladen und angezeigt werden. Natürlich müsste nach dem FF_CloseDialog noch der Stack durch entsprechend (n-1)-faches FF_PopImage aufgeräumt werden. Wobei noch die Frage hinsichtlich der insgesamt verfügbaren Stackpositionen zu kären wäre.*)
Demgegenüber ist dann schon das Laden des Original-Images inkl. Herunterrechnen auf die Thumbgröße während der Ausführung des Befehles FF_ShowDialog die zwar zeitaufwändigere aber letztlich einfachere Lösung.
Gruß
Heinrich
*) P.S.: Woher hast Du die Anzahl 10?
Hallo Werner,
die "Speicherstelle", von der ein Image geladen werden soll, ist nicht das Problem. Egal ob man ein Bild von Position 0 (= unmittelbarer Arbeitsspeicher) oder irgendeiner Position (1, 2 ... usw.) vom Stack holt oder vorher durch FF_PopImage auf Position 1 und dann mit FF_SwapImage gegen das im Arbeitsspeicher tauscht oder durch ein weiteres FF_PopImage ganz in den Arbeitsspeicher bringt, spielt für die eigentliche Abbildung im Dialogelement vom Typ IMAGE keine Rolle.
Der Hintergedanke war, dass bei einer Vielzahl von Images (Thumbs) in einem Dialog aus Timinggründen sinnvollerweise nicht die kompletten Images mit ihrer hohen Pixelzahl geladen und dann entsprechend auf das Thumbmaß heruntergerechnet werden sollten, sondern mit FF_LoadThumb direkt die Vorschaubild in den Speicher und von da aus in das IMAGE-Element transferiert werden sollten.
Aber das geht so einfach leider nicht. Bei IMAGE-Elementen werden anders als bei BUTTON-, STATIC- oder sonstigen Elemente nicht die Bildinhalte schon mit FF_SetControl dorthinein transferriert, sondern nur die Zeiger oder Pfade auf die jeweiligen Images. Erst bei der Ausführung von FF_ShowDialog werden die Bildinhalte für die IMAGE-Fenster über die jeweils hinterlegten Pfad- bzw. Zeigerangaben geholt und dargestellt.
Einzige - aber m.E. unpraktische - Lösung wäre, jedes Thumb-Image mit FF_LoadThumb in den Arbeitsspeicher zu laden, mit FF_PushImage auf den Stack zu puschen und in den IMAGE-Elementen mit FF_SetControl die jeweils richtige Stackposition (n-1, n-2, ..., 1, 0) zu hinterlegen. Dann könnte mit FF_ShowImage das jeweilige Thumb-Image aus der richtigen Speicherposition in das entsprechende IMAGE-Fenster geladen und angezeigt werden. Natürlich müsste nach dem FF_CloseDialog noch der Stack durch entsprechend (n-1)-faches FF_PopImage aufgeräumt werden. Wobei noch die Frage hinsichtlich der insgesamt verfügbaren Stackpositionen zu kären wäre.*)
Demgegenüber ist dann schon das Laden des Original-Images inkl. Herunterrechnen auf die Thumbgröße während der Ausführung des Befehles FF_ShowDialog die zwar zeitaufwändigere aber letztlich einfachere Lösung.
Gruß
Heinrich
*) P.S.: Woher hast Du die Anzahl 10?
AW: Skripting - Grundlagen und Allgemeines
*)Lange her, weiß nicht mehr
. Kann mich auch irren.
FF_LoadThumb geht in der Regel so schnell, dass es keine Probleme bereitet. Nutze es schon, seit es den Befehl gibt. Inzwischen kann man ja auch dafür sorgen, dass auch ein Bild und nicht nur die Baustelle angezeigt wird.
Den Stack hatte ich eigentlich für Deine Benutzerelemente gedacht. Dann brauchst Du nicht von der Platte nach laden(obwohl ich's tue. Cache machts möglich).
Wenn Du vorab ein Hilfsfenster (Copyright etc.) aufblendest und im Hintergrund weiter arbeitest, fällt eine längere Ladezeit gar nicht mehr auf. Neue Dialogfunktionen machen es möglich (FF_RefreshDialog).
Wenn Du größere Bilder als Vorschaubildgröße brauchst: Die IMAGE-Controls skalieren selbst runter, allerdings nicht rauf (Ob es dauerhaft nur den Speicher für die Anzeigegröße oder für das ganze Bild verbraucht, weiß ich nicht. Wenn nein, gibt es Optimierungsbedarf)! Hier ist auf Dialogeinheiten zu achten!
Ggf. muss eine Bild vergrößert werden, damit es vollständig darin angezeigt wird. Dazu sollte man bei der Entwicklung gelegentlich auch mal von Windows die Dialogeinheiten ändern, um zu kontrollieren. Besonders, wenn man Bilder für Schaltflächen benützt, wie z. B. bei WPInfo.
*)Lange her, weiß nicht mehr
. Kann mich auch irren.FF_LoadThumb geht in der Regel so schnell, dass es keine Probleme bereitet. Nutze es schon, seit es den Befehl gibt. Inzwischen kann man ja auch dafür sorgen, dass auch ein Bild und nicht nur die Baustelle angezeigt wird.
Den Stack hatte ich eigentlich für Deine Benutzerelemente gedacht. Dann brauchst Du nicht von der Platte nach laden(obwohl ich's tue. Cache machts möglich).
Wenn Du vorab ein Hilfsfenster (Copyright etc.) aufblendest und im Hintergrund weiter arbeitest, fällt eine längere Ladezeit gar nicht mehr auf. Neue Dialogfunktionen machen es möglich (FF_RefreshDialog).
Wenn Du größere Bilder als Vorschaubildgröße brauchst: Die IMAGE-Controls skalieren selbst runter, allerdings nicht rauf (Ob es dauerhaft nur den Speicher für die Anzeigegröße oder für das ganze Bild verbraucht, weiß ich nicht. Wenn nein, gibt es Optimierungsbedarf)! Hier ist auf Dialogeinheiten zu achten!
Ggf. muss eine Bild vergrößert werden, damit es vollständig darin angezeigt wird. Dazu sollte man bei der Entwicklung gelegentlich auch mal von Windows die Dialogeinheiten ändern, um zu kontrollieren. Besonders, wenn man Bilder für Schaltflächen benützt, wie z. B. bei WPInfo.
AW: Skripting - Grundlagen und Allgemeines
Hallo Heinrich,
fast liest es sich so an, als hättest Du eine Lösung für den Direktzugriff auf eine Stack-Position gefunden. Ist aber wohl so, dass Du den Stack der Reihe nach wieder abbauen würdest - oder? Ist ein 2. Stack im Scipting denkbar, um durch 'umstapeln' auf eine Stackposition direkt zugreifen zu können?
VG
Walter
Hallo Heinrich,
fast liest es sich so an, als hättest Du eine Lösung für den Direktzugriff auf eine Stack-Position gefunden. Ist aber wohl so, dass Du den Stack der Reihe nach wieder abbauen würdest - oder? Ist ein 2. Stack im Scipting denkbar, um durch 'umstapeln' auf eine Stackposition direkt zugreifen zu können?
VG
Walter
AW: Skripting - Grundlagen und Allgemeines
Hallo Walter,
Du kannst mit einer Ordnungsnummer (z. B. FF_SetControl Dlg, Control, "3") direkt zugreifen. Nur Austauschen über FF_SwapImage ist kompliziert. Planung vorab tut also not.
Mir persönlich wäre ein Bild-Objekt lieber, nur gibt's da Probleme, dies per Skripting bereitzustellen. Offenbar haben die einzelnen Skriptsprachen unterschiedliche Zugriffsorganismen. Darum gehen auch z. B. Arrays nicht.
Hallo Walter,
Du kannst mit einer Ordnungsnummer (z. B. FF_SetControl Dlg, Control, "3") direkt zugreifen. Nur Austauschen über FF_SwapImage ist kompliziert. Planung vorab tut also not.
Mir persönlich wäre ein Bild-Objekt lieber, nur gibt's da Probleme, dies per Skripting bereitzustellen. Offenbar haben die einzelnen Skriptsprachen unterschiedliche Zugriffsorganismen. Darum gehen auch z. B. Arrays nicht.