Delphi-PRAXiS
Seite 3 von 4     123 4      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Autostart über Registry (https://www.delphipraxis.net/2541-autostart-ueber-registry.html)

fedderle 28. Jan 2003 20:53

Zitat:

Zitat von Daniel B
es muss nicht sein das ich mit meinen "kleinen progrämchen" auch noch was dazu beitrage, wo man noch andere möglichkeiten hat.

In dem Punkt muss ich dir zustimmen. Mich nervt es auch immer, wenn ich nach fast jeder Installation von nem Programm in der Registry das Ding wieder aus dem Autostart rausnehmen muss, weil ich es gar nicht im Autostart haben möchte.
Auf der anderen Seite find ich das mit dem Autostart in der Registry aber auch praktisch. Man denke nur mal an Benutzer, die sich am Rechner fast gar nicht auskennen. Die klicken da irgendwo rum un verschieben oder löschen den Link aus dem Autostartordner.

Aber so generell muss ich sagen, dass Du mich überzeugt hast. Man könnte aber vielleicht einen Kompromiss eingehen und den Benutzer vor der Installation fragen, ob er das Programm überhaupt im Autostart haben möchte.

OK! Jetzt schweif zu sehr vom eigentlichen Thema ab.

Brüggendiek 28. Jan 2003 21:08

Hallo!

Oh weh - da ist aber wohl einer seeeehr mutig - die compilierte EXE direkt aus dem Projektverzeichnis zu benutzen!
Was ist denn, wenn Du noch Änderungen hat/eine neue Version schreibst? Bis zur Fertigstellung ist das Programm nicht benutzbar.

Meine Programme kommen nach Fertigstellung einer Version immer in einen getrennten Ordner und werden zum Anwenden daraus gestartet. Dann kann ich neu compilieren, ohne eine funktionsfähige und ggf. benötigte EXE zu verlieren! Außerdem passiert es dann nicht, daß beim Compilieren die EXE noch geöffnet ist.

Gruß

Dietmar Brüggendiek

Daniel B 28. Jan 2003 21:46

Zitat:

Zitat von Brüggendiek
Außerdem passiert es dann nicht, daß beim Compilieren die EXE noch geöffnet ist.

Delphi-Quellcode:
var
  mHandle: THandle;

implementation
{$R *.dfm}

[...]

initialization //Verhindern, dass ein Programm mehrmals gestartet wird
  mHandle := CreateMutex(nil, True, 'NameDerExe');
  if GetLastError = ERROR_ALREADY_EXISTS then
  begin
    Halt;
  end;

finalization
  if mHandle <> 0 then
  begin
    CloseHandle(mHandle);
  end;

end.
Grüsse, Daniel :hi:

Daniel B 28. Jan 2003 21:51

Zitat:

Zitat von fedderle
Man könnte aber vielleicht einen Kompromiss eingehen und den Benutzer vor der Installation fragen, ob er das Programm überhaupt im Autostart haben möchte.

Das würde auch Sinn machen, wenn man das anklickt, dann weiss man "meistens" schon was man dadurch bewirkt und wie man den Link auch wieder findet. Und einfach! löschen kann, ohne in der Registry suchen zu müssen.

Bei Office oder Corel oder andere wirklich grossen Anwendungen kann ich es verstehen und hab auch kein Problem damit, solange alles wieder entfernt wird.
Aber wenn sich jeder Snake-Clon wie sich hier viele rumtreiben, in die Registry einträgt, dann krieg ich so ein Hals.

Grüsse, Daniel :hi:

Brüggendiek 28. Jan 2003 22:19

Hallo!

@Daniel B: 1. kenne ich den Code mit dem Mutex bereits.
2. verhindert das ja nicht, daß ich die Exe neu compilieren will, während das Programm noch (nicht von der IDE gestartet) läuft.

Ich wollte darauf hinweisen, daß man eigene Programme, und wenn es nur mit einem einfachen Kopieren ist, in einem Verzeichnis ausserhalb der Delphi-Sources installieren sollte. Sonst zerstört man sich möglicherweise beim Compilieren eine funktionsfähige Version.
Eine der Fragen lautete ja, warum der Compiler die EXE nicht schreiben will. Das zeigt mir an, daß der Benutzer die fertige EXE nicht kopiert hat und diese noch läuft.

Nebenbei: über bedingte Compilierung und einen Boolean-Parameter bei der Mutex-Erzeugung stelle ich sogar sicher, daß die Produktions- und die Entwicklungsversion parallel laufen können, aber jede nur einmal!

Gruß

Dietmar Brüggendiek

bubabo 29. Jan 2003 06:12

Servus,
Das Compilieren funktionierte deshalb nicht, weil die exe-Datei nach gestartet war.
Ist diese .free-Anweisung unbedingt nötig und was bewirkt sie?

Daniel B 29. Jan 2003 06:54

Zitat:

Zitat von bubabo
Ist diese .free-Anweisung unbedingt nötig und was bewirkt sie?

Natürlich, alles was Du Createst, z.B. bei der Registry, oder bei eine Ini, musst Du auch wieder freigeben, um Ressourcen zu sparen.
Das macht man mit Reg.Free; oder noch besser, FreeAndNil(Reg);.

Grüsse, Daniel :hi:

bubabo 29. Jan 2003 17:13

Hallo,
ich hab ständig rumprobiert und es hat alles nichts gebracht.
Jetzt versuche ich es über den Autostartordner mit dieser Funktion:

Delphi-Quellcode:
uses activeX,comobj,shlobj;

const
  IID_IPersistFile: TGUID = (D1:$0000010B;D2:$0000;D3:$0000;D4:($C0,$00,$00,$00,$00,$00,$00,$46));


function CreateLink(PathObj,PathLink,Desc,Workdir:string):Boolean;
var psl : IShellLink;
    ppf : IPersistFile;

begin
  result := False;
  if SUCCEEDED(CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_INPROC_SERVER, IID_IShellLinkA, psl)) then begin
    psl.SetPath(PChar(PathObj));
    psl.SetDescription(PChar(Desc));
    psl.SetWorkingDirectory(PChar(workdir));
    if SUCCEEDED(psl.QueryInterface(IID_IPersistFile,ppf)) then begin
      ppf.Save(StringToOLEStr(PathLink),TRUE);
      Result := true;
    end;
  end;
end;

Doch auch hier gibt es wieder Probleme. Zwar wird eine Datei erstellt (ich übergebe Pathlink den Namen der Verknüpfung
'Name des Programms.ink'), doch es wird keine Verknüpfung, sondern eine .ink-Datei, bei der ich dann gefragt werde, mit welchem Programm ich sie öffnen will.
[/quote][/delphi]

Brüggendiek 29. Jan 2003 20:57

Hallo!

Was sollen den ".INK"-Dateien sein???? :shock: Oder sind vielleicht doch eher ".LNK"-Dateien gemeint????

Gruß

Dietmar Brüggendiek

bubabo 29. Jan 2003 21:18

Hallo Dietmar,
ich meine damit
Zitat:

".INK"-Dateien


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:03 Uhr.
Seite 3 von 4     123 4      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz