PB EasySetup - Setup für eigenes Programm erstellen

[Thorsten1867]

Da wird ein Mutex erstellt, wie ich oben beschrieben habe

Tja, da werde ich wohl um Mutex nicht herumkommen.
Ich habe die Source-Datei studiert, war aber nicht ganz so hilfreich. Als ich mich das letzte Mal an Assembler versucht habe, galt noch der Z80 (CPU) als State of the art.
Sobald ich das Konzept von Mutex durchsachaut habe, werde ich mich wohl an die Arbeit machen. Ich hoffe irgendjemand kann mich diesbezüglich "erleuchten".

Übrigens bräuchte ich dann zu möglichst vielen Programmiersprachen die Codebeispiele, da EasySetup ja nicht nur von PureBasic Nutzern genutzt wird.

[ts-soft]

ASM und PureBasic Syntax für Mutex haste doch jetzt, für Profan kannste
auch haben, wenn gewünscht. Für Delphi findeste im Kochbuch für Delphi ein
Mutex-Beispiel. Wirste schon zusammenkriegen, so einen simplen API-Aufruf

Gruß
Thomas

[mk-soft]

Von Mutex in den Programm einzubauen halte ich gar nichts.
Das Setup sollte alles packen können und nicht abhängig sein das in den Programmen auch noch ein Mutex zu programmieren ist.

Liefer über WindowTitel oder ClassName suchen.

FF

[Kaeru Gaman]

yo genau.

ein setup, das ich nicht unabhängig verwenden kann,
das ich nicht einfach auf mein fertiges projekt aufsetzen kann,
würde ich überhaupt nicht verwenden.

....und damit steh ich gewiß nicht allein.

[ts-soft]

>> Liefer über WindowTitel oder ClassName suchen.

Such mal im engl. Forum, dort haben die einen Link zu einer MS-Aussage gepostet, warum das sehr unsicher ist.
Es sei denn, man nutzt einen eigenen Classennamen, der aber schwerer zu erstellen ist, als ein Mutex

Normallerweise erfolgt nur eine Aufforderung, das alle noch offenen
Anwendungen zu schließen sind, der Rest ist nur eine Zusatzfunktion, die nur
einen Sinn erfüllt, wenn sie Sicher ist, also mit Mutex, Semaphore oder Atom.
Nicht mit Fenstertext.

[Kaeru Gaman]

gut, ts, wenn du so schlau bist, dann mach doch ne möglichkeit.

als grenze wäre es noch denkbar,
die fertige .exe zu wrappen mit nem kleinen proggi das den mutex erzeugt.

aber vom programmierer erwarten, manuell aufs setup-program abzustimmen, halte ich für kontraduktiv.

damit bekommt er das nicht auf ner heft CD los.

[ts-soft]

@Kaeru Gaman
Zusatzfunktion, nicht erforderlich!

Ansonste reagiert er auf den Fehler, wenn das überschreiben nicht klappt,
wäre natürlich sinnvoll, vorher alles was überschrieben werden soll, erstmal
als Rollback zu sichern.

Unsinnige Fehlermeldungen ausgeben, bloß weil so ein Fenstername oder
Classenname gefunden wird, ist Unproffessionell

[Thorsten1867]

Ich denke es spricht nichts dagegen, beides zu verwenden.
Wenn kein Mutex existiert, verwendet man halt die unsichere Methode.
Die Mutex-Methode würde sowieso in der Sparte "Erweiterte und fortgeschrittene Funkionen" landen, die den Normaluser nicht weiter stören sollten.

Falls jemand einen Link oder einen Codeschnippsel zur unsicheren Merhode hat, wäre es schön, wenn er sie hier posten würde, dann muss ich nicht das ganze Forum absuchen.

[mk-soft]

Bastelei

Code: Alles auswählen

Procedure FindAllWindow()

  WindowName.s
  ClassName.s
  temp.s
  
  hwnd = GetWindow_(WindowID(0),#GW_HWNDFIRST)
  *buffer = AllocateMemory(16384)
  While hwnd
    len = GetWindowText_(hwnd,*buffer, 16384)
    WindowName = PeekS(*buffer, len)
    len = GetClassName_(hwnd , *buffer, 16384)
    ClassName = PeekS(*buffer, len)
    temp = WindowName + " - " + ClassName
    Debug temp
    hwnd = GetWindow_(hwnd,#GW_HWNDNEXT)
  Wend

EndProcedure

FF

[ts-soft]

Bei den meisten Editoren usw. ändert sich der Fenstertitel im
Programmablauf, dann lieber drauf verzichten und nur auf Fehler beim
überschreiben reagieren. So in der Form, ist das Setup für mich oft nicht
mehr nutzbar.