einfaches Programm mit Statusfenster

[ripper8472]

Hi,

Ich will ein Prog schreiben, das aus den Daten in paramstr() etwas macht, dabei den Fortschritt anzeigen soll und nach getaner Arbeit terminiert. Das Statusfenster würde ich gerne zur Designzeit designen können (also nix mit dyn. Erzeugen des Fensters). Wo packe ich den Code also am besten hin? (Konsolenapp oder Fensterapp, in welches Event?)

Danke

[fkerber]

Hi!

So ganz verstehe ich nicht, was du machen möchtest, aber ich versuch mich mal dran

Statusfenster ==> Fensterapplikation

irgendwas ausführen am besten im OnCreate
aber was genau willst du machen?


Ciao fkerber

[ripper8472]

Ich schreibe mir ein Programm, mit dem ich SFV Dateien erzeugen kann (CRC32 von Dateien berechnen). Die Algos habe ich, genauso wie die Shellintegration.
Das Programm wird mit den Dateien als Parametern gestartet und geht dann die angegebenen Dateien durch. Dabei soll der Anwender in einem Statusfenster sehen, wie weit mein Prog ist. Dieses Statusfenster soll das einzige Fenster der Anwendung sein. Wenn das Prog fertig ist, dann soll es von allein wieder schließen. Ein Tool eben.
Funktionsbeispiel: WinRAR sitzt auch im Kontextmenü. Ich markiere einige Files, gehe ins Kontextmenü, wähle "Hinzufügen zu archiv.rar" und der Packer macht (und zeigt seinen Status an). Wenn er fertig ist, verschwindet er wieder. Genauso will ich das machen.

Mit OnCreate ist das meiner Meinung nach extrem unsauber, weil das Fenster erst nach OnCreate angezeigt wird. Wenn ich die Anwendung schon im OnCreate terminiere (Halt(), Application.Close, Application.Terminate,...), dann schreit der Compiler.

trotzdem danke für deinen Vorschlag

Gruß, Christoph

[fkerber]

Hi!

Axo, sowas hast du vor.
Dann empfehle ich dir eher Form1.Show, oder?


Ciao fkerber

[ripper8472]

:oops: :roll:

Ähhh, sorry, ich glaub ich mach das am besten in C++.
Ich befinde mich nämlich grad in der Übergangsphase zu C/++ (C/++ wird im Studium häufiger benutzt) und bin etwas zerrissen, wen ich wo fragen soll und ob ich die Antworten portieren kann.

Mit Delphi/Builder fühl ich mich nicht so richtig crossplatform-konform.
Ich hatte gehofft, nicht mit den Events arbeiten zu müssen, sondern mit irgendwas in Richtung WinAPI/nonVCL, weil mir das mehr vom System vermittelt und mir Pascal besser beibringt.

Zumindest hab ich die Shellintegration und die Algorithmen für CRC32 und MD5 fertig. Für den Anfang kann ich mir ja erstmal ein Konsolenapp schreiben, um die Routinen fertig zu haben.

dank dir, fkerber

[Beckman]

faende ich aber viel praktischer, wenn das app in der konsole bleibt. inkl seiner statusanzeige.

weil entweder ist es ein console app, dann verwend ichs in der console (wnen ich kein zugang zu X, ahm ich mein das winGUI hab) oder ich machs halt grafisch.
dann mach so mit 'open file'


nja, mein senf :D

[shmia]

Zitat:

Zitat von ripper8472

Ich will ein Prog schreiben, das aus den Daten in paramstr() etwas macht, dabei den Fortschritt anzeigen soll und nach getaner Arbeit terminiert. Das Statusfenster würde ich gerne zur Designzeit designen können (also nix mit dyn. Erzeugen des Fensters). Wo packe ich den Code also am besten hin? (Konsolenapp oder Fensterapp, in welches Event?)

Du baust eine ganz einfache Anwendung mit einem Formular.
Im Anhang ist eine Demoanwendung, die du als Vorlage verwenden kannst. Der Knackpunkt ist die
"Autostart"-Funktion; die Anwendung fängt selbstständig an zu arbeiten, anstatt auf Benutzereingaben
zu warten.

Zu deinen Überlegungen zu C++ und WinAPI/nonVCL kann ich dir sagen:
Mit Delphi bist du um eine Mehrfaches schneller fertig !!!
Die EXE-Datei hat am Ende dann zwar 600kB statt vielleicht 80kB und braucht etwas mehr Resourcen,
aber gesch..... drauf.
Mit Delphi+VCL kann man sich auf die eigentlichen Aufgaben konzentrieren, statt sich mit
Windows-Handles und anderem Low-Level Dingen herumzuplagen.

[ripper8472]

Danke für das Beispielprogramm. Das automatische Starten der Routinen ist mit Abstand das sauberste, was mir mit Events und Messages möglich erscheint.
Allerdings kommt es bei mir nicht auf eine einfache Lösung für dieses Problem an,
sondern dass ich mit C/++ und dem System (Win und andere) in Kontakt komme.
Dieses Programm hätte ich schon vor einer ganzen Weile fertig haben können, wenn ich es quick'n'dirty haben wollte. Ich möchte es aber sauber, ohne Ballast, um es delphi zu sagen: nonVCL.


Ich hab inzwischen herausgefunden, wie man einem Konsolenapp die Konsole abgewöhnt: man löscht die {$APPTYPE CONSOLE} Direktive!
Das einzige Problem ist, dass ich das Formular zur Designzeit bearbeiten will und nicht per Quelltext. Das geht. Einfach ein "Neues Formular" aus dem Datei-Menü verlangen.
Nur bekomme ich das Fenster nicht angezeigt (hab noch nicht viel probiert).
Hat da jemand Ahnung, wie ich dieses Fenster anzeige und auf die Kompos zugreifen kann?

Danke

[Luckie]

Ich verstehe ehrlich gesagt nicht so ganz, was du da vor hast bzw. wie du dir das vorstellst. Ohne weitere Tricks schließen sich eine Konsole und eine GUI Anwendung schon mal aus. Wenn du es ohne VCL machen willst, um näher am System zu sein, dann empfehle ich dir meine "Win32 API Tutorials für Delphi" http://tutorials.luckie-online.de Kuck dir das mal an, da wird dir eventuell klarer was du eigentlich willst.

Desweiteren:

Zitat:

Ich hatte gehofft, nicht mit den Events arbeiten zu müssen, sondern mit irgendwas in Richtung WinAPI/nonVCL, weil mir das mehr vom System vermittelt und mir Pascal besser beibringt.

Das widerspricht sich eigentlich. Denn willst du es ohne VCL machen bist du mehr mit der WinAPI beschäftigt als mit der Sprache Delphi und ohne Grundlagen in der Sprache wird es noch mal um so schwieriger, da was auf die Beine zu stellen. Deswegen, solltest du dir erstmal die Grundlagen der Sprache beibringen und dann kucken, wie du weiter machst. Aber wenn du keine ahnung weder von der Programmierung mit der API hast, noch die Grundlagen der Sprache beherrscht, wirst du sehr schnell frustriert sein.

[ripper8472]

wusst ich's doch! sobald jemand "nonVCL" sagt, kommt der Luckie zur Rettung :wink: :-D
dank dir für die Hilfe


mit den Grundlagen der Sprache ist es nicht das Problem, sondern dass ich mir nonVCL noch nicht angesehen hab. Deine Tutorials werde ich in der nächsten Zeit durcharbeiten. Im Forum hab ich einen Thread gesehen, in dem du deine nonVCL Templates auf deiner Page verlinkst. Allerdings scheinen die umgezogen zu sein. Gibt es diese Templates noch?

Wo ich "Events" gesagt hab, meinte ich das Tab "Ereignisse" eines VCL Programms. Alles ins onCreate (o.ä.) zu packen und dann app.terminate zu machen fand ich einen unnötigen Umweg und unsauber.

ein "Konsolen"-App schließt doch keine Fenster aus. Wenn ich aus dem Konsolena-App ein nicht-Konsolen-App mache (die Direktive $apptype löschen), dann hab ich doch schon fast was ich will. Nur muss ich dann mein Fenster selber erstellen mit TForm.create. Allerdings denke ich, dass ich dann Probleme mit den Messages für dieses Fenster haben werde, weil die ja nirgends verarbeitet werden. Also werd ich mir mal deine Tuts ansehen.

Danke

[bigg]

hi,

1.genau das meinte Luckie ja, komm weg von dem Gedanken, du könntest mit 2 Zeilen
Code ein Formular erstellen. Zumindest nicht mit nonVCL.

2. Die VCL ist nicht schlecht, in großen Projekten ist Sie unverzichtbar.
Programme laufen stabil und meist ohne Probleme. (wenn sie ordentlich programmiert wurden)

Kurz und knapp, wenn du nonVCL programmieren willst, mußt du auf Units wie:
Classes, Forms, und Co. verzichten.

Du kannst auch nicht mal Ebenen eine Komponente einbinden
und diese für dein Projekt nutzen.

Aber einige Vorteile hat das Ganze und um nur den wichtigsten zu nennen,
man lernt eine ganze Menge dabei.

[ripper8472]

Ich glaube auch nicht, dass man mit irgendwas unter 30 Zeilen nonVCL ein Formular erstellen könnte.

Klar, VCL ist prima. Wenn ich z.B. C++ für verschiedene Plattformen schreiben will, dann mach ich das auch nicht für jede Plattform mit der entsprechenden API, sondern nehm ne GUI library. (soll jetzt nicht heißen, dass ich das schon gelernt hab) Genauso bekomm ich mit VCL echt schnell Anwenderprogramme hin, die ihren Zweck erfüllen sollen und nie opensource gehen.

Verzicht auf Units ist mir klar. Aber man kann sich ja immer noch die gebrauchten Funktionen rauskopieren oder einfach selber schreiben.

Komponente einbinden geht zwar nicht, aber man kann sich vielleicht den Code dieser ansehen und die Funktionsweise adaptieren.

Jep, lernen will ich das, solange mein Hirn das noch freudig mitmacht. Nur kann ich nicht alles auf einmal lernen (nonVCL, Threads, Win32API, C++, GUI Libs wie GTK/wxWidgets/Qt, Linux/Unix, Assembler...). Aber ich hab ja Zeit, noch. Schritt für Schritt kleine Testproggies für die Funktionsweise und am Ende bin ich einer von den Großen.

Gruß, Christoph