Pascal Project Manager & Editor

[Harry Stahl]

@ jziersch:

Ich verwende eigentlich immer nur Delphi selber zum compilieren, mit dem händischen Aufruf des externen Compilers habe ich nur wenige Erfahrungen.

Hast Du ein Beispiel, wie ich ein Projekt mit welchen Parametern aufrufen müsste, damit es kompiliert (und dabei z.B. Suchpfade, etc. richtig berücksichtigt)? Und einmal als Release, bzw. einmal als Debug-Version?

By the way: Habe gerade ein neues Video hochgeladen, das einmal zeigt, wie man recht schnell ein einfaches VCL-Formular und die darin enthaltene Programmlogik mit Hilfe des Pascal-Editors nach FMX konvertieren kann:

https://youtu.be/rpN6C9Y1yHg

Dies kann z.B. dann eine Hilfe sein, wenn einem der Mida-Konverter [http://midaconverter.com] nicht (auf einem bestimmten PC oder gar nicht) zur Verfügung steht oder man eine Konvertierung einfach nur Schritt für Schritt durchführen möchte.

Die gezeigte Erweiterung (nun auch Images aus einer FMX-Imagelist einzeln exportieren zu können), ist in der aktualisierten Version 3.22 bereits Online.

Edit: Ach ja: Auch habe ich die Programme schon mal auf die kommende Version Delphi 10.4 soweit wie möglich angepasst, nach den "üblichen Regeln", wie bislang immer Versionsnummern etc. geändert wurden (aus allgemein zugänglichen Quellen, z.B. kein Beta-Test-Wissen oder ähnliches). Da noch nicht bekannt ist, wie Delphi 10.4 mal später genau heißen wird, erscheint derzeit noch ein Delphi 10.4 XXX, das dann später bei Release von Delphi 10.4 durch den richtigen Namen ersetzt wird.

Die Programmteile zur Anzeige von VCL und FMX-Formulare wurden daher mit Delphi 10.3.3 kompiliert und werden spätern mit 10.4 aktualisiert, wenn verfügbar. Der Lazarus-Part wurde auf 2.08 aktualisiert (hier wurden auch eine ganze Reihe von Komponenten für die Anzeige in Formularen hinzugenommen, wie etwa Synedit oder letzte neuere Komponenten).

[jziersch]

Zitat:

Zitat von Harry Stahl (Beitrag 1462438)

Ich verwende eigentlich immer nur Delphi selber zum kompilieren, mit dem händischen Aufruf des externen Compilers habe ich nur wenige Erfahrungen.

Natürlich während der Entwicklung läuft das in der IDE, wenn es aber darum geht ein Update heraus zu bringen wird ein script angeworfen, welches z.b. eine Reihe von DLLs erzeugt.

Das kompilieren aus der IDE birgt immer das Risiko, dass durch einer Konfigurationsänderung das Projekt entweder nicht oder falsch kompiliert wird. Durch das kompilieren durch einem direkten Aufruf vermeidet man auch das Problem dass ein vergessenes Compilersymbol im Projekt (z.b. DEBUG) ein unerwünschtes Ergebnis erzeugt. Auch kann ein Projekt mit einem festgelegten Setup von Komponenten gebaut werden, also z.b. einer früheren Version von WPTools also der aktuellen die in der IDE installiert ist.

Zitat:

Zitat von Harry Stahl (Beitrag 1462438)

Hast Du ein Beispiel, wie ich ein Projekt mit welchen Parametern aufrufen müsste, damit es kompiliert (und dabei z.B. Suchpfade, etc. richtig berücksichtigt)? Und einmal als Release, bzw. einmal als Debug-Version?

Debug und Release unterscheidet sich bei mir nur durch ein compiler symbol, also z.b. kann -DDEBUG dem Compiler übergeben werden.

Ansonsten funktioniert Deine Methode eigentlich, nur dass eben alle Verzeichnisse eingebunden werden müssen, die man zu einem bestimmten Zeitpunkt aus der IDE ausgelesen hat.
Das auslesen geht ja bereits mittels des Knopf rechts oben, das Ergebnis müsste nur noch abgespeichert und verwendet werden.

Das ist vor allem der jeweilige Bibliothekspfad und der Suchpfad. Es ist für dein Programmes meiner Meinung nach unabdingbar, dass dieser Pfad mit verwaltet wird. Denn es geht doch darum, ein Projekt so genau wie möglich zu erfassen, also alle Abhängigkeiten zu kennen.

Zusätzlich sollte man compiler Symbole angeben können.

Code:

C:\Borland\DX12\Bin\dcc32.exe -DWPDFREGDLL -NSVcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell;Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap; -DWPDF3 -DWPDF4 -$D- -B+ C:\S\wPDF\Source\
Compile_wPDF_DLL.dpr

Hier wird aus dem Verzeichnis mit allen Compilern (heißt bei mir "Borland" und beinhaltet 19 Delphi Editionen in friedlicher Koexistenz) Delphi 10.2 gestartet um die wPDF DLL zu erzeugen. Dabei wird ein Quellverzeichnis hinzugefügt. Mehr ist eigentlich nicht dabei.

Die Ausgabe des Compilers könnte man (wie ich oben schrieb) dazu verwenden, alle Units zu listen welche wirklich verwendet werden.

[jziersch]

Etwas feedback zu der aktuellen Version:

1) Der Editor ist sehr schön, übersichtlich und nutzbar.

2) Die Formularansicht funktioniert gut. Ich fände es noch toll wenn die Struktur und die Textansicht zusammenarbeiten würden, sodass die Struktur Schachtelungen anzeigt und sowohl Klick (Auswahl) als auch Drag&Drop Operationen (Verschieben) auf der Textansicht anwenden könnte.

3) Beim Öffnen eines Projektes wurden bei einem Projekt alle Dateien unter "Projektdateien" gelistet, ohne Rücksicht darauf ob die verwendet werden. Ist das so gewünscht?

4) Beim Compilieren wird die Ausgabe verkürzt, es wird immer nur der Projektname gelistet. Sinnvoll wäre es die Ausgabe auszuwerten, z.b. nur Fehler zu listen und zusätzlich die verwendeten units anzugeben.

5) Bei DLL Projekten sollte für die Ausführung eine consumer EXE angebbar sein.

[dummzeuch]

[QUOTE=jziersch;1462443]

Zitat:

Zitat von Harry Stahl (Beitrag 1462438)

Zitat:

Zitat von Harry Stahl (Beitrag 1462438)

Hast Du ein Beispiel, wie ich ein Projekt mit welchen Parametern aufrufen müsste, damit es kompiliert (und dabei z.B. Suchpfade, etc. richtig berücksichtigt)? Und einmal als Release, bzw. einmal als Debug-Version?

Debug und Release unterscheidet sich bei mir nur durch ein compiler symbol, also z.b. kann -DDEBUG dem Compiler übergeben werden.

Edit: Sorry, ich hatte das "bei mir" überlesen. Das ist natürlich legitim, aber unüblich: Gibt es wirklich keine unterschiedlichen Compiler-Einstellungen?

Nein, die beiden Konfigurationen (und theoretisch weitere, die man anlegen kann) unterscheiden sich potentiell durch jede einzelne mögliche Compiler- und Linker-Option, durch unterschiedliche Suchpfade und ggf. auch noch unterschiedliche Pre-/Post-Scripts. Ach ja, habe ich schon die Versionsinfos erwähnt?

Üblicherweise ist bei mir z.B. im Debug-Modus die Optimierung ausgeschaltet, es werden Debug-DCUs verwendet, es werden diverse Laufzeit-Checks eingeschaltet. Im Release-Modus ist es dann umgekehrt, selbst Assertions sind bei Relesaes manchmal aus.

Es ist aber eigentlich auch recht einfach, diesen Modus an msbuild zu übergeben, der Rest passiert dann genauso wie in der IDE:

Code:

call "%DelphiPath%\bin\rsvars.bat"
msbuild myproject.dproj /target:rebuild /p:config=debug

Dabei muss man %DelphiPath% natürlich passend setzen, so das rsvars.bat gefunden wird.

Edit:
Bei Delphi 2007 ist es ein wenig anders:

Code:

call "%DelphiPath%\bin\rsvars.bat"
msbuild myproject.dproj /target:rebuild /p:Configuration=debug

(also Configuration statt Config).

[Harry Stahl]

OK, vielen Dank Euch beiden für die hilfreichen Hinweise.

Ich bastele gerade ein wenig daran rum, siehe anliegenden Screenshot.

Habe also den Aufruf des Kompilierungsvorgangs in einen eigenen Dialog gelegt, wo man bestimmte Auswahlen treffen kann.

DCC funktioniert wie bisher. Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Und wie, für welche Plattform (Windows, MAC, usw) erzeugt werden soll?

Außerdem werden anscheinend alle Plattformen mit diesem Aufruf erzeugt, oder?

Wenn man den DCC-Compiler verwendet und man dort die Suchpfade angeben will (ist Das der "-I" oder "-U" Parameter?) kann der dann selber solche Angaben auflösen wie:

$(crossvcl)\Lib\$(ProductVersion)\$(Platform)\$(Co nfig)

?

Wo schreibt der DCC-Compiler eigentlich die erzeugten DCU-Units hin, ich kann die hier im Moment gar nicht finden?

[jziersch]

-E<path> = Ausgabeverzeichnis für EXE
-N<path> = DCU-Ausgabeverzeichnis
-O<paths> = Objektverzeichnisse

Hier die Optionen für Delphi 7:

Code:

Syntax: dcc32 [optionen] dateiname [optionen]

  -A<unit>=<alias> = Unit-Alias setzen   -LU<package> = Package verwenden
  -B = Alle Units erzeugen               -M = Modifizierte Units erzeugen
  -CC = Ziel: Konsole                    -N<path> = DCU-Ausgabeverzeichnis
  -CG = Ziel: GUI                        -O<paths> = Objektverzeichnisse
  -D<syms> = Bedingungen definieren      -P = Auch nach 8.3-Dateinamen suchen
  -E<path> = Ausgabeverzeichnis für EXE  -Q = Ohne Meldung compilieren (Quiet)
  -F<offset> = Suchfehler                -R<paths> = Ressourcenverzeichnisse
  -GD = Detaillierte Map-Datei           -U<paths> = Unit-Verzeichnisse
  -GP = Map-Datei mit publics            -V = Debug-Information in EXE
  -GS = Map-Datei mit Segmenten          -VR = Externe Fehlersuche gen.
  -H = Ausgabe von Hinweismeldungen      -W = Ausgabe von Warnungen
  -I<paths> = Include-Verzeichnisse      -Z = Ausgabe nie zu erstellender DCPs
  -J = .obj-Dateien generieren           -$<dir> = Compiler-Direktive
  -JP = C++-.obj-Datei generieren       --help = Diesen Hilfebildschirm anzeigen
  -K<addr> = Image-Basisadresse          --version = Name und Version anzeigen
Compiler-Schalter: $<buchst><status> (Vorgabewerte siehe unten)
  A8  Ausgerichtete Record-Felder         P+  Offene String-Parameter
  B-  Vollst.  boolesche Auswertung       Q-  Integer-Überlaufprüfung
  C+  Zur Laufzeit Bedingungen auswerten  R-  Bereichsüberprüfung
  D+  Debug-Information                   T-  Typisierter @-Operator
  G+  Importierte Datenreferenzen verw.   U-  Pentium(tm)-sichere Division
  H+  Standardmäßig lange Strings verw.   V+  Strenge Prüfung von var-Strings
  I+  Ein-/Ausgabeprüfung                 W-  Stack-Frames erzeugen
  J-  Strukt. Consts (Schreibzugriff)     X+  Erweiterte Syntax
  L+  Lokale Debug-Symbole                Y+  Symbolinformation
  M-  Laufzeit-Typinfo (RTTI)             Z1  Mindestgröße für Enum-Typen
  O+  Optimierung

Für Delphi 10.3 - 64 bit

Code:

Syntax: dcc64 [Optionen] Dateiname [Optionen]

  -A<unit>=<alias> = Unit-Alias setzen
  -B = Alle Units erzeugen
  -CC = Ziel: Konsole
  -CG = Ziel: GUI
  -D<syms> = Bedingungen definieren
  -E<path> = EXE/DLL-Ausgabeverzeichnis
  -F<offset> = Fehlersuche
  -GD = Detaillierte Map-Datei
  -GP = Map-Datei mit publics
  -GS = Map-Datei mit Segmenten
  -H = Ausgabe von Hinweismeldungen
  -I<paths> = Include-Verzeichnisse
  -J = .obj-Dateien generieren
  -JPHNE = C++ .obj-Datei, .hpp-Datei, im Namespace erzeugen, alles exportieren
  -JL = Package-.lib, -.bpi und alle .hpp-Dateien für C++ erzeugen
  -K<addr> = Image-Basisadresse
  -LE<path> = Package .bpl-Ausgabeverzeichnis
  -LN<path> = Package .dcp-Ausgabeverzeichnis
  -LU<package> = Package verwenden
  -M = Modifizierte Units erzeugen
  -NU<Pfad> = Unit-DCU-Ausgabeverzeichnis
  -NH<path> = Unit .hpp-Ausgabeverzeichnis
  -NO<path> = Unit .obj-Ausgabeverzeichnis
  -NB<path> = Unit .bpi-Ausgabeverzeichnis
  -NX<Pfad> = Unit-XML-Ausgabeverzeichnis
  -NS<namespaces> = Namespace-Suchpfad
  -O<paths> = Objektverzeichnisse
  -P = Auch nach 8.3-Dateinamen suchen
  -Q = Ohne Meldung compilieren (Quiet)
  -R<paths> = Ressourcenverzeichnisse
  -TX<Erw.> = Erweiterung des Ausgabenamens
  -U<paths> = Unit-Verzeichnisse
  -V = Debug-Information in EXE
  -VR = Externe Fehlersuche gen.
  -VT = Debug-Informationen in TDS
  -VN = TDS-Symbole im Namespace
  -W[+|-|^][warn_id] = Ausgabe von Warnmeldungen
  -Z = Ausgabe nie zu erstellender DCPs
  -$<dir> = Compiler-Direktive
  --help = Diesen Hilfebildschirm anzeigen
  --version = Name und Version anzeigen
  --codepage:<cp> = Codierung für Quelltextdatei festlegen
  --default-namespace:<namespace> = Namespace setzen
  --depends = Unit-Abhängigkeitsinformationen ausgeben
  --doc = XML-Ausgabedokumentation
  --drc = Ausgabe-Ressourcenstring .drc-Datei
  --no-config = Standard-dcc64.cfg-Datei nicht laden
  --description:<String> = Beschreibung für ausführbare Datei festlegen
  --inline:{on|off|auto} = Inlining von Funktionen steuern
  --legacy-ifend = Alte $IFEND-Direktive zulassen
  --zero-based-strings[+|-] = Indizierung der Strings beginnt mit 0
  --peflags:<Flags> = Zusätzliches Flags-Feld für PE-Header setzen
  --peoptflags:<Flags> = Zusätzliches Feld für optionale Flags für PE-Header setzen
  --peosversion:<Haupt>.<Neben> = BS-Versionsfelder in PE-Header setzen (Vorgabe: 5.0)
  --pesubsysversion:<Haupt>.<Neben> = Untersystem-Versionsfelder in PE-Header setzen (Vorgabe: 5.0)
  --peuserversion:<Haupt>.<Neben> = Benutzer-Versionsfelder in PE-Header setzen (Vorgabe: 0.0)
  --lib-version:<Version> = Version des Ausgabe-Package-Namens
  --lib-suffix:<Suffix> = Suffix des Ausgabe-Package-Namens

Je nach Platform gibt es ja verschiedene compiler, also auch OSX...

Ich halte es für wichtig wahlweise den compiler direkt anzusprechen (und nicht MSBuild), da man dadurch Projekt unabhängig kompilieren kann. Also alles was man im Projekt (*.dproj) oder den Pfaden evtl. verstellt hat spielt keine Rolle, und man erhält wirklich das Ergebnis so, wie es im Projekt Manager hinterlegt ist. Auch funktioniert DCxx sehr zuverlässig.

[dummzeuch]

Zitat:

Zitat von Harry Stahl (Beitrag 1462461)

Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Und wie, für welche Plattform (Windows, MAC, usw) erzeugt werden soll?

Du kannst Dir von der IDE den Aufruf für's compilieren anzeigen lassen. Ich weiß nur gerade nicht mehr, wo man das einstellt.

twm

[Harry Stahl]

Zitat:

Zitat von dummzeuch

Edit:
Bei Delphi 2007 ist es ein wenig anders:

Code:

call "%DelphiPath%\bin\rsvars.bat"
msbuild myproject.dproj /target:rebuild /p:Configuration=debug

(also Configuration statt Config).

Ist das NUR bei Delphi 2007 so oder bei Delphi 2007 und allen älteren Versionen (also Delpi 2006, 2005 ,usw)?

Edit: Habe gerade eine aktualisierte Version hochgeladen (HP weist das aber nicht aus), wo die Compiler-Funktion als BETA integriert ist, sieht so aus wie in Anlage. Im Feld "Zusätzliche Parameter" kann man bei Bedarf weitere benötigte Parameter angeben (Muss man wohl, da ich derzeit noch nicht für den DCC-Compiler weiß, was ich da zwingend selber ermitteln müsste, damit es richtig läuft).

Das compilieren mit dem MSBuild-Compiler scheint aber schon ganz gut zu funktionieren.

[himitsu]

Und wenn z.B. "lange" Suchpfade mit rein sollen, dann besser der Weg über die CFG-Datei, also dort die "Parmerter" rein, denn all zu lang darf die Parameterliste des DCC nicht werden.

[ringli]

Zitat:

Zitat von Harry Stahl (Beitrag 1462461)

Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Ich hoffe das beantwortet deine Frage:

Code:

msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win32 /p:config=Release
msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win64 /p:config=Release

[jziersch]

@Harry

Grossartig, es läuft viel weiter. Jetzt kommen auch lesbare Fehlermeldungen.

Mein grosses FMX Projekt konnte msbuild kompilieren und es wurde die Ausgabe Datei erstellt. Allerdings zeigt sich der Naschteil hier, da eben die Einstellungen des Projektes komplett verwendet werden und die EXE in dem dort eingestellten Verzeichnis erstellt wird. Das ist zwar oft gewünscht, aber nicht immer, gerade bei einem Projekt welches man schon ewig nicht mehr angefasst hat. Mir geht es darum ein Projekt so in PPM zu erfassen, dass es immer kompilierbar ist, mit den gespeicherten Pfaden etc, unabhängig von der IDE die evtl. bereits andere Komponenten verwendet. Es sieht so aus, als ob genau das kommt. Toll!

DCC, was mich daher insbesondere interessier lief auch ganz gut. Besonders zeigt sich dass hier alle units gelistet werden. Es ist die method um die Abhängigkeiten zu finden. Könnten die direkt so in das Projekt in PPM eingetragen werden? Ganz wichtig ist die DCC Pfade auch im Projekt abzuspeichern, also für später.

In meinem Fall kommt:

C:\....\unitname.pas(42) Schwerwiegend: F2613 Unit 'SysUtils' nicht gefunden.

Das problem war ein fehlender namespace. Keine grosse Sache.

Ich habe auch ein paar Symbole mit -D... als parameter hinzugefügt. Funktioniert insgesamt sehr gut.

Kannst Du bitte vielleicht einen Knopf auf deinem neuen Formular anbringen "Parameter in Projekt merken", sodass die Einstellungen, parameter und(!) Pfade genau wie verwendet für den nächsten Aufruf gespeichert werden. Dann wäre es perfekt, denke ich.

[dummzeuch]

Zitat:

Zitat von Harry Stahl (Beitrag 1462530)

Zitat:

Zitat von dummzeuch

Edit:
Bei Delphi 2007 ist es ein wenig anders:

Code:

call "%DelphiPath%\bin\rsvars.bat"
msbuild myproject.dproj /target:rebuild /p:Configuration=debug

(also Configuration statt Config).

Ist das NUR bei Delphi 2007 so oder bei Delphi 2007 und allen älteren Versionen (also Delpi 2006, 2005 ,usw)?

Delphi < 2007 unterstützt soweit ich mich erinnere kein msbuild. Zumindest habe ich damals in den Build-Scripten für GExperts explizit dcc32 Aufrufe eingebaut, während alle neueren Versionen msbuild benutzen.


Compile from comandline im Delphi Wiki stimmt mir da zu (kein Wunder, die Seite habe ich damals selbst angelegt. ;-) )

[Harry Stahl]

Zitat:

Zitat von himitsu (Beitrag 1462536)

Und wenn z.B. "lange" Suchpfade mit rein sollen, dann besser der Weg über die CFG-Datei, also dort die "Parmerter" rein, denn all zu lang darf die Parameterliste des DCC nicht werden.

Danke für den Hinweis.

Was genau ist "nicht allzu lang" und wie verwendet man die .CFG-Datei (einfach da die Parameter rein, wie sonst in der Paramaterübergabe) und wie bindet man die .cfg-Datei ein?

Zitat:

Zitat von ringli (Beitrag 1462545)

Zitat:

Zitat von Harry Stahl (Beitrag 1462461)

Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Ich hoffe das beantwortet deine Frage:

Code:

msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win32 /p:config=Release
msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win64 /p:config=Release

Gerade eben erst gesehen. Ja danke, damit gehts...

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1462549)

@Harry

Grossartig, es läuft viel weiter. Jetzt kommen auch lesbare Fehlermeldungen.

Mein grosses FMX Projekt konnte msbuild kompilieren und es wurde die Ausgabe Datei erstellt. Allerdings zeigt sich der Naschteil hier, da eben die Einstellungen des Projektes komplett verwendet werden und die EXE in dem dort eingestellten Verzeichnis erstellt wird. Das ist zwar oft gewünscht, aber nicht immer, gerade bei einem Projekt welches man schon ewig nicht mehr angefasst hat. Mir geht es darum ein Projekt so in PPM zu erfassen, dass es immer kompilierbar ist, mit den gespeicherten Pfaden etc, unabhängig von der IDE die evtl. bereits andere Komponenten verwendet. Es sieht so aus, als ob genau das kommt. Toll!

DCC, was mich daher insbesondere interessier lief auch ganz gut. Besonders zeigt sich dass hier alle units gelistet werden. Es ist die method um die Abhängigkeiten zu finden. Könnten die direkt so in das Projekt in PPM eingetragen werden? Ganz wichtig ist die DCC Pfade auch im Projekt abzuspeichern, also für später.

In meinem Fall kommt:

C:\....\unitname.pas(42) Schwerwiegend: F2613 Unit 'SysUtils' nicht gefunden.

Das problem war ein fehlender namespace. Keine grosse Sache.

Ich habe auch ein paar Symbole mit -D... als parameter hinzugefügt. Funktioniert insgesamt sehr gut.

Kannst Du bitte vielleicht einen Knopf auf deinem neuen Formular anbringen "Parameter in Projekt merken", sodass die Einstellungen, parameter und(!) Pfade genau wie verwendet für den nächsten Aufruf gespeichert werden. Dann wäre es perfekt, denke ich.

Habe die aktualisierte Version gerade hochgeladen, Dialog sieht nun so aus, wie in der Anlage. Pro Projekt wird nun eine Datei mit dem Namen der Projekt-Datei, aber Dateiendung '.pecs" (für PascalEditorCompilerSettings) in das Projektverzeichnis gespeichert.

In dieser Datei werden dann die Einstellungen für den Dialog gespeichert, man kann derzeit bis zu 25 unterschiedliche Compiler-Settings pro Projekt anlegen (kann ich erhöhen, falls das nicht reichen sollte).

Programm merkt sich auch die zuletzt verwendeten Settings und stellt diese dann wieder her, wenn man den Dialog erneut aufruft (ist ganz praktisch, wenn man mit den DCC-Paramentern ein wenig herumspielt).

Bezüglich MSBuild: Da lese ich nun aus der rsvars.bat das richtige Framework aus (ab Delphi 10.3 ja wohl Framework 4), so dass der entsprechende MSBuild-Compiler verwendet wird.

[jziersch]

Hallo Harry,

Hier noch etwas feedback zu aktuellen 3.23

1) Ich falle immer darauf ein, dass ein Doppelklick die IDE startet. Kann man das so konfigurieren, dass sich der PPME öffnet?

2) Die Kompilation mit msbuild ist erfolgreich. Allerdings wird die ausführbare Datei bei mir ganz woanders erstellt, eben wie im Projekt angegeben. Dort wird sie aber von PPME nicht gefunden.

3) Die Logik der Parameter Speicherung scheint mir nicht nicht ganz perfekt zu sein. Bei einem erneuten Öffnen von PPME sind die Einträge nicht mehr da.

4) Ein msbuild Lauf erzeugt bei mir


Compiling:
S:\MyProjects\....dproj

...

_PasCoreCompile:
C:\Delphi\DX13\bin\dcc64.exe -$D0 -$L- -$Y- --no-config ... MeinProjekt.dpr

Diese Zeile nach "_PasCoreCompile" beinhaltet alle Parameter und Suchpfade für eine direkte Ausführung des Dxx compilers. PME könnte diese Zeile auswerten und in die Konfiguration des Projektes aufnehmen. Damit kann DCC zu einem späteren Zeitraum direkt ausgeführt werden. Ich habe dies in einer BAT Datei gemacht, und es wurde anstandslos ein Projekt erzeugt.

Interessant wäre die Auswertung der Parameter
-ED:\xxxx AUSGABEVERZEICHNIS
-Ic:\Delphi\dx13\lib\Win64\re SUCHPFAD
-Rc:\Delphi\dx13\li Weiterer Suchpfad
-Uc:\Delphi\ Weiterer Suchpfad
-NU.\Win64\Release Die Units
-NSWinapi;System.Win;Data.Win;Datasnap Die namespaces

Ich habe probiert diese Werte manuell für den Aufruf von DCC einzutragen, nur leider hat das nicht geklappt, da es immer einen 32/64 bit Versionsfehler gab. Prinzipiell müsste es aber gehen, die BAT Datei funktioniert ja.

Wieso sich der Aufwand mit DCC lohnt:

1) Über DCC (und andere Dxxx) kann man ein Projekt immer kompilieren, sofern man die Parameter
archiviert hat, unabhängig von der aktuellen Konfiguration. Also auch nach Jahren, wenn man nur die Pfade nicht geändert hat.

2) Es lässt sich über --doc -NXpfad für jede source unit eine XML Datei generieren, dies kann helfen alle eingebundenen units zu finden. Die Haupt XML Datei des Projektes enthält alle eingebunden namespaces / units:

Code:

<namespace name="MeinProject" platform="Win64">
  <contains name="FMX.Filter.Effects" />
  <contains name="FMX.Filter.Standard" />
  <contains name="FMX.ComboTrackBar" />
  <contains name="FMX.ComboTrackBar.Style" />

was sich dazu anbietet, von PME ausgewertet zu werden.

Viele Grüsse,
Julian

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1463196)

Hallo Harry,

Hier noch etwas feedback zu aktuellen 3.23

1) Ich falle immer darauf ein, dass ein Doppelklick die IDE startet. Kann man das so konfigurieren, dass sich der PPME öffnet?

Ich habe in der aktuellen Version 3.26 jetzt unter Extras, Optionen, Programmverhalten eine Option eingebaut, dass man wählen kann, was sich per Doppelklick öffnet (IDE oder Pascal Editor).

Hinweis: Dumzeuch hatte sich mal einen Modifier für das Starten per Returntaste gewünscht (gehaltene Shift-Taste öffnete dann den Pascal-Editor, statt IDE), was ich auch eingebaut hatte.

Wenn man nun den Doppelklick auf das Projekt als Standard so umstellt, dass sich der Pascal-Editor öffnet, hat Return+Shift-Taste nun den umgekehrten Effekt, öffnet dann also die IDE.

Zitat:

Zitat von jziersch (Beitrag 1463196)

2) Die Kompilation mit msbuild ist erfolgreich. Allerdings wird die ausführbare Datei bei mir ganz woanders erstellt, eben wie im Projekt angegeben. Dort wird sie aber von PPME nicht gefunden.

Hatte ich schon in Version 3.25 verbessert, dass aus dem Projekt der Exe-Ausgabepfad ausgelesen wird und PE daher dort das Programm startet.

Zitat:

Zitat von jziersch (Beitrag 1463196)

3) Die Logik der Parameter Speicherung scheint mir nicht nicht ganz perfekt zu sein. Bei einem erneuten Öffnen von PPME sind die Einträge nicht mehr da.

Die Einstellungen werden für jedes Projekt separat gespeichert (Projekt-Dateiname, Endung durch '.pecs' ersetzt). Wenn Du also ein anderes Projekt öffnest, gibt es dort erst mal keine Einträge.

Die anderen von Dir erwähnten Dinge sehe ich mir an und prüfe, was ich machen kann.

Die nächsten Dinge die auf dem Plan stehen, sind Direkt-Zip der Projekt-Dateien bzw. eine Dokumentationsfunktion (angelehnt an Documentation insight).

[Harry Stahl]

Ich bin gerade dabei, die schon mal vor einiger Zeit angekündigte Dokumentations-Funktion einzubauen.

Dazu habe ich erst mal eine Möglichkeit geschaffen, die Parameter, die Delphi selber als XML-Dokumentations-Tags anbietet, wenn man Strg+J drückt, mit Hilfe eines kleinen Dialog-Fensters sehr viel einfacher eingeben oder ändern zu können, siehe anliegenden Screenshot.

XML-Parameter gibt es aber auch weitere, daher wollte ich mal hier die Frage stellen, ob man zusätzliche Parameter hier anbieten sollte (vgl: https://docs.microsoft.com/de-de/dot.../codedoc#param) oder reicht es im Prinzip so?

Weiterhin: Ich überlege, ob ich kurze Einträge statt mehrzeilig, einzeilig erfassen soll,

also statt:

/// <summary>
/// Looks for a special Message
/// </summary>

lieber so:

/// <summary>Looks for a special Message</summary>

Gibt es irgendwelche Tools, die damit nicht zurecht kommen oder andere Gründe diese 2. Variante nicht zu wählen? Immerhin nimmt diese nur eine Zeile weg.
Bei 3 unterschiedlichen XML-Tags mit kurzen Einträgen hätte man nur 3 statt 9 Zeilen...

Hinweis: Diese Funktion ist noch nicht in der Version auf meiner HP enthalten...

[Harry Stahl]

Die Projekt-Dokumentations-Funktion ist zwar immer noch Beta, aber sehr weit fortgeschritten. Man kann mit der aktuellen Version 3.22 bereits umfangreiche HTML-Dokumentationen aus im Source befindlichen XMLDoc-tags generieren.

Ich habe mal ein kurzes Video zum aktuellen Stand gemacht, wer will kann gerne hier oder auf Youtube ein Feedback geben:

https://youtu.be/G_rmGixTlso

Ich denke, Dokumentation von Software ist oft unterschätzt und ich muss gestehen, dass ich als Einzelkämpfer in der Vergangenheit da zu nachlässig war. Aber ich merke schon jetzt wie hilfreich es ist, wenn allein nur schon kurze Beschreibungen von Units oder kurze Ablaufpläne den Durchblick in länger nicht bearbeitete Projekte immens erhöhen...

[Harry Stahl]

Hi, habe mal ein paar kleinere Erweiterungen in die Version 3.50 eingebaut und zwar eine Auswahl der Forms über einen erweiterten Dialog, der auch die Form-Images anzeigt und eine andere Darstellung des Object-Inspektors (siehe 2 screenshots in der Anlage).

Habe auch ein kleines Video dazu auf YouTube hochgeladen:

https://youtu.be/aEtFuKqFgBA

[Gandalf2265]

Hallo Harry,

ich habe es gerade geladen und probiert. Super Sache!
Danke...

[Harry Stahl]

Zitat:

Zitat von Gandalf2265 (Beitrag 1475336)

Hallo Harry,

ich habe es gerade geladen und probiert. Super Sache!
Danke...

Hallo Thorsten,
danke für Dein Feedback!

[Harry Stahl]

Gerade habe ich die aktualisierte Version 3.51 auf meine Homepage (https://www.hastasoft.de/PPME.htm) geladen, die auch Delphi 10.4.2 unterstützt, in dem Sinne das exakt die richtige Delphi-Version erkannt wird und die neuen VCL-Controls (TControlList und andere) im Formular-Viewer angezeigt werden.

Damit kann man nun auch die Schriftgröße in Delphi selber (also den Font im Objekt-Editor und der anderen Listen-Elemente) wechseln bzw. die Größe ändern (Schalter IDE-Manager klicken, dort auf "Optionen" im Dialog gewünschte IDE auswählen Font und Font-Größe setzen). Mein Delphi habe ich direkt auf Font-Größe 10 umgestellt, das ist soviel angenehmer zu arbeiten...

Daneben sind weitere verbesserte Kleinigkeiten, wenn man z.B. im Pascal-Editor in einem geöffneten Projekt den String einer Caption-Eigenschaft in die Zwischenablage kopiert (Kontext-Menü der Eigenschaft im Objekt-Inspektor des Pascal-Editors), dann wird aus

Code:

'Dies ist ein Beispiel f'#252'r ein Element mit mehrzeiligem Text. Sie' +
' k'#246'nnen ein beliebiges TGraphicControl darauf platzieren und Eig' +
'enschaften anpassen.'

Code:

Dies ist ein Beispiel für ein Element mit mehrzeiligem Text. Sie können ein beliebiges TGraphicControl darauf platzieren und Eigenschaften anpassen.

Zwar nur aber eine kleine, aber nützliche Erweiterung, wenn man Caption-Texte von einem anderen Projekt in das aktuelle Projekt übernehmen möchte...

[Harry Stahl]

Ein kleines 2:50 Minuten Video, das zeigt wie man das aktuell gerade in Delphi bearbeitete Projekt ganz schnell in den Pascal Editor laden kann und dabei auch direkt die aktuelle bearbeitete Unit geöffnet wird.

Optional kann man dabei eine Zeilennummer angeben, so dass der Cursor direkt auf die Passende Zeile gestellt wird.

https://youtu.be/ZIiDhd7Mjo0

Siehe auch anliegenden Screenshot

[jziersch]

Das funktioniert wirklich gut. Mit gefällt auch die Möglichkeit ein Projekt direkt aus dem PPE zu kompilieren. Mit msbuild geht das sehr gut.

Aufgefallen ist mir dass: (1) Änderungen in der angezeigten Unit nicht automatisch gespeichert werden, das könnte vielleicht eine Option sein. (2) Der Schalter "Ausführen", die Auswahl 32/64 bit etc behalten nicht ihre Einstellung.
Es fehlt die Möglichkeit ein "Komplettes Build" zu erzwingen, also *alle* units zu kompilieren.
Bei der DCC Kompilierung klappt das nicht (immer) - dann kommt ein "Kann nicht ausführen Fehler" welcher sogar fatal ist.

Ich suche eine Möglichkeit alle Units zu listen (am besten in einer exportierbaren editierbaren Liste bei der ich auch prefixe, also z.b. ein ZIP aufruf, sowie postfixe angeben kann) die vom Projekt tatsächlich verwendet werden. Es geht darum wirklich alle units zu finden für eine vollständige Archivierung. Ich könnte mir vorstellen, dass dafür die Ausgabe des Build Prozesses ausgewertet (-fileLogger) werden kann.

Viele Grüsse,
Julian

[Aviator]

Sieht interessant aus. Ich habe auf deinem Screenshot aber noch einen Schreibfehler gespottet :stupid:

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1484611)

Das funktioniert wirklich gut. Mit gefällt auch die Möglichkeit ein Projekt direkt aus dem PPE zu kompilieren. Mit msbuild geht das sehr gut.

Aufgefallen ist mir dass:

(1) Änderungen in der angezeigten Unit nicht automatisch gespeichert werden, das könnte vielleicht eine Option sein.

(2) Der Schalter "Ausführen", die Auswahl 32/64 bit etc behalten nicht ihre Einstellung.

(3) Ich suche eine Möglichkeit alle Units zu listen (am besten in einer exportierbaren editierbaren Liste bei der ich auch prefixe, also z.b. ein ZIP aufruf, sowie postfixe angeben kann) die vom Projekt tatsächlich verwendet werden. Es geht darum wirklich alle units zu finden für eine vollständige Archivierung. Ich könnte mir vorstellen, dass dafür die Ausgabe des Build Prozesses ausgewertet (-fileLogger) werden kann.

Viele Grüsse,
Julian

zu (1) Da ja das Programm in erster Linie dazu gedacht ist, die Informationen aus den Projekten zu extrahieren, werden Änderungen nicht automatisch gespeichert, da könnte ja auch was ungewolltes dabei sein, aber es findet immer eine Abfrage beim Schließen statt.

zu (2) Man muss dazu einmal einen Namen für ein Compilersettings anlegen (siehe im anliegenden Screenshot gelbe und grüne Markierung) und explizit speichern. Dann werden bei der nächsten Auswahl die Werte auch wiederhergestellt.

Möchte anmerken, dass diese Option der Compilierung nur eine sehr rudimentäre ist und nur recht eingeschränkt funktioniert.

(3) Wenn Du unter "Dokumentation" den Befehl "Erstellen" aufrufst, wird in der Hauptübersicht eine Auflistung aller Projekt-Units vorgenommen. Reicht das evtl.?

[Harry Stahl]

Zitat:

Zitat von Aviator (Beitrag 1484647)

Sieht interessant aus. Ich habe auf deinem Screenshot aber noch einen Schreibfehler gespottet :stupid:

Danke, habe ich in der eben aktualisierten Fassung 3.53 direkt mit behoben.

[jziersch]

Zitat:

Zitat von Harry Stahl (Beitrag 1484683)

zu (1) Da ja das Programm in erster Linie dazu gedacht ist, die Informationen aus den Projekten zu extrahieren, werden Änderungen nicht automatisch gespeichert, da könnte ja auch was ungewolltes dabei sein, aber es findet immer eine Abfrage beim Schließen statt.

Dann bräuchte es m.M.n. diese Abfrage bevor das Compilieren startet.

Ich sehe das Compilieren nicht nur als Mittel um mal schnell ohne die IDE ein Projekt zu bauen, sondern auch um wertvolle Information aus dem Compilierprozess zu gewinnen. (s.u.)

Zitat:

Zitat von Harry Stahl (Beitrag 1484683)

(3) Wenn Du unter "Dokumentation" den Befehl "Erstellen" aufrufst, wird in der Hauptübersicht eine Auflistung aller Projekt-Units vorgenommen. Reicht das evtl.?

Nein - ich hatte mir vorgestellt, dass wenn ich meine WPTools Demo kompiliere auch alle pascal units gelistet werden, die von diesem Projekt mittelbar reingezogen werden. Also auch alle 3rdparty units, in diesem Fall eben die WPTools units.
Nur dann kann ich wirklich ein Projekt sicher archivieren.


Grüsse,
Julian

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1484685)

Zitat:

Zitat von Harry Stahl (Beitrag 1484683)

zu (1) Da ja das Programm in erster Linie dazu gedacht ist, die Informationen aus den Projekten zu extrahieren, werden Änderungen nicht automatisch gespeichert, da könnte ja auch was ungewolltes dabei sein, aber es findet immer eine Abfrage beim Schließen statt.

Dann bräuchte es m.M.n. diese Abfrage bevor das Compilieren startet.

Ich sehe das Compilieren nicht nur als Mittel um mal schnell ohne die IDE ein Projekt zu bauen, sondern auch um wertvolle Information aus dem Compilierprozess zu gewinnen. (s.u.)

Zitat:

Zitat von Harry Stahl (Beitrag 1484683)

(3) Wenn Du unter "Dokumentation" den Befehl "Erstellen" aufrufst, wird in der Hauptübersicht eine Auflistung aller Projekt-Units vorgenommen. Reicht das evtl.?

Nein - ich hatte mir vorgestellt, dass wenn ich meine WPTools Demo kompiliere auch alle pascal units gelistet werden, die von diesem Projekt mittelbar reingezogen werden. Also auch alle 3rdparty units, in diesem Fall eben die WPTools units.
Nur dann kann ich wirklich ein Projekt sicher archivieren.


Grüsse,
Julian

OK, Abfrage vor compilieren ist sinnvoll, werde ich einbauen.
Die 3rdparty units, die unter uses (vor und nach implementation) stehen, sollte ich auch rausfinden und irgendwie zugänglich machen können (schon jetzt kann man sich ja units anzeigen lassen, die nicht im Projekt gelistet sind, aber über die Uses und die Suchpfade reinkommen), werde ich mir mal ansehen.

Edit: Abfrage vor compilieren ist eingebaut (neben der Beseitigung eines Bugs), siehe Anlage. Version 3.54 ist auf Homepage verfügbar.

[Harry Stahl]

Die neue, erweiterte Version 4.0 gibt es jetzt auch als kostenlose Community Edition. Sie ist kaum im Vergleich zur kommerziellen Vollversion beschränkt (an wenigen Stellen etwas reduzierter Komfort, z.B. keine farbigen Strukturlinien im Editor).

Bei der neuen Version ist insbesondere der Pascal Project Manager intensiv überarbeitet worden (vgl. anliegenden Screenshot).
So ist der bisherige IDE-Manager in der Hauptform integriert worden und für Projekt- und Dokumentenverwaltung gibt es jetzt eigene Ansichten und Schalter. Auch werden die Informationen zum ausgewählten Projekt nicht mehr in einer kleinen Zeile am Fußende angezeigt, sondern an der rechten Seite mir ausreichend viel Platz. Ferner gibt es nun auch ein richtiges Menü, nicht nur Schalter.

Auch kann man unter "Projektdateien" nun direkt die zum Projekt gehörenden Dateien einsehen (und öffnen oder kopieren), man muss also nicht erst das ganze Projekt öffnen, um in eine Datei rein zu sehen.

Die neue Version unterstützt nun auch Delphi 11 Alexandria.

Die Homepage muss ich noch bezüglich der Info zur Community Edition aktualisieren, aber man erhält im Download schon die aktuelle Version 4.

https://hastasoft.de/PPME.htm

[Harry Stahl]

Nun habe ich es (mit kleinen zusätzlichen Erweiterungen) auch endlich geschafft ein kurzes Video über die neue Version 4 zu machen:

https://youtu.be/_abhEyEMIac

Und noch mal zur Erinnerung, das Programm kann jetzt auch als Free Community Editon verwendet werden, diese Version ist im Vergleich zur kommerziellen Kaufversion nur ganz minimal (in "Komfort-Bereichen") beschränkt, aber alle Funktionen sind ansonsten voll nutzbar.

Was ich im Video noch erwähnt haben wollte, wozu das gut ist, die Projekteinstellungen mal als externe Datei zu exportieren: Hin und wieder will man mal entweder einige Einstellungen in ein anderes Projekt übernehmen bzw. man muss u.U. auch schon mal eine Projekt-Datei neu aufbauen, wenn die irgendwie größere Probleme macht. Da ist es dann ganz hilfreich, wenn man die wesentlichen Einstellungen des Projekts zur Hand hat und per Copy und Paste wieder in Delphi übernehmen kann.

Kleiner Tipp: Schaut mal in die Video-Beschreibung rein, die gibt es eine Sprungliste zu den einzelnen Kapiteln des Videos.

[Harry Stahl]

In einem 8 Minuten Video die letzten Neuerungen : https://youtu.be/RFGEYUP3EUI

(u.a:

- Neuer Tab "Projects" im IDE-Manager zeigt zuletzt geöffnete Projekte und Favoriten sowie Delphi-Demos an ;
- Neue Ansicht für die .dproj oder .deployproj Dateien in der strukturierten Treeview-Ansicht
)

Alles was im Video gezeigt wird steht auch in der freien Comunitiy Edition des Programms zur Verfügung
(der Beitrag hat in den Informationen zum Video ein Inhaltsverzeichnis mit direkt anspringbaren Video-Positionen, so kann man sich schnell orientieren, bzw. nur das ansehen, was einen evtl. interessiert).

[Harry Stahl]

In der aktualisierten Version 4.15 wird nun auch Delphi Alexandria (incl. 11.2) unterstützt, ein 4-minütiges Mini-Video zeigt die Änderungen: https://youtu.be/lTVbrEMxMmU

Falls ich es noch nicht erwähnt habe: Wenn man den Pascal Project Manager (zusätzlich) als PlugIn für die Welcome-Page nutzt (per Einbindung der WPPM.bpl unter "Komponente", "Packages installieren", können bisherige User des WUPDI-Tools (das ja nur bis 10.42 nutzbar ist) die dort eingepflegten Projekte importieren (über den Menü-Button meines PlugIns).

Der Pascal Project Manager & Editor (incl. PlugIn) können in der leicht eingeschränkten Fassung einer "Community Edition" kostenlos verwendet werden.

https://www.hastasoft.de/PPME.htm

[Harry Stahl]

Hallo Zusammen,

ich arbeite gerade an der neuen Version 5 (die es wie die Version 4 auch weiterhin auch als freie Community-Edition geben wird).

Ich habe das Programm gehörig "aufgebohrt" und mit einer Reihe von neuen Funktionen versehen.

Insbesondere soll es nun nicht mehr nur die Delphi-Projekte statisch verwalten, sondern das Prozessmanagement bei der Programmentwicklung unterstützen.
Mit TODo-, Feature,- und Bug-Listen sollen anstehende Bearbeitungspunkte erfasst und mit Hilfe eines Kanban-Boards abgearbeitet werden.

Das Programm ist in erster Linie für Einzelentwickler gedacht, es wird aber auch eine Netzwerkfähige Version geben, die mit PC-Database Server zusammenarbeitet, dann können bei Bedarf auch mehrere Entwickler gleichzeitig an den Projekten arbeiten.

Ferner verwaltet es die in den Projekten benutzten Komponenten oder Tools, die man zusammen mit Delphi benutzt (im Sinne, welche Version, wo ist die Setup-Datei, wo die Lizenzdaten und Keys).

So, das mal als Kurzabbriss für die neue Version.

Als Anlage habe ich mal ein paar Screenshots beigefügt, daraus kann man schon ganz gut erkennen, welche Daten so verwaltet werden.

Mich würde interessieren,

1. ob die augenscheinlich erfassten Daten zum Delphi-Projekt ausreichen oder ob was fehlt?
2. sind die Daten für das Kanban-Board so OK oder fehlt noch eine wichtige Info?
3. Sollte ich noch eine "How-To" Liste hinzufügen, wo man Tipps zur Programmentwicklung verwalten kann?

[jziersch]

Hallo Harry,

das Kanbanboard finde ich super. Ich denke es fehlen aber die Spalten
Draft - für reine Ideen
ToDo - woran noch nicht gearbeitet wird

Ich hatte ja vor vielleicht 2 Jahre eine Version lizensiert, aber nie richtig eingesetzt. Für meine Zwecke fehlt die Möglichkeit der Identifizierung aller verwendeten Units. Also auch jener units die indirekt eingebunden werden. Die Verzeichnisansicht hilft mier hier nicht weiter, da ich sowieso einen leistungsfähigen Dateimanager verwende.

Wenn es eine Liste mit ausgeschlossenen Pfaden gäbe, z.b. "C:\Embarcadero\*", könnte man das Auflisten von System Units verhindern, dennoch aber Komponenten mit einbinden.

Der PME sollte dann die Möglichkeit haben diese Units in einer Liste auszugeben (mit der Möglichkeit batch befehle einzufügen) sowie die Dateien in einem Archiv zu sichern.

Grüsse,
Julian

[jziersch]

Zitat:

Sollte ich noch eine "How-To" Liste hinzufügen, wo man Tipps zur Programmentwicklung verwalten kann?

Ich würde eher an eine allgemeine Liste denken. Hier sollten aber auch binäre Daten verwaltbar sein, zumindest aber jeweils ein ZIP zugeordnet sein. Z.b. um einen Privat Key abzuspeichern, Passwörter für den Server etc. Idealerweise sollte das alles zumindest mit einem Masterpasswort gesichert sein.

[jziersch]

Zitat:

ob die augenscheinlich erfassten Daten zum Delphi-Projekt ausreichen oder ob was fehlt?

Information über erforderliche Tools, also externe Projekte wie DLLs aber auch Graphik Dateien. Für meine Icons verwende ich z.b. Affinity Designer, die jeweiligen Quelldateien würde ich gerne verlinken.

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1512787)

Hallo Harry,

das Kanbanboard finde ich super. Ich denke es fehlen aber die Spalten
Draft - für reine Ideen
ToDo - woran noch nicht gearbeitet wird

Ich hatte ja vor vielleicht 2 Jahre eine Version lizensiert, aber nie richtig eingesetzt. Für meine Zwecke fehlt die Möglichkeit der Identifizierung aller verwendeten Units. Also auch jener units die indirekt eingebunden werden. Die Verzeichnisansicht hilft mier hier nicht weiter, da ich sowieso einen leistungsfähigen Dateimanager verwende.

Wenn es eine Liste mit ausgeschlossenen Pfaden gäbe, z.b. "C:\Embarcadero\*", könnte man das Auflisten von System Units verhindern, dennoch aber Komponenten mit einbinden.

Der PME sollte dann die Möglichkeit haben diese Units in einer Liste auszugeben (mit der Möglichkeit batch befehle einzufügen) sowie die Dateien in einem Archiv zu sichern.

Grüsse,
Julian

Danke für Dein Feedback.

Die Spalte "Backlog" entspricht eigentlich dem "ToDo" hier wird oft entweder die eine oder die andere Bezeichnung verwendet.
Für reine Ideen würde ich entweder die eigene Projekt ToDo-Liste nehmen (daher der Name "Backlog" im Kanban, um eine Unterscheidung zu haben" oder die Featureslist. In das Backlog sollten keine reine Ideen rein, sondern nur Aufgaben, die aktuell zur Bearbeitung anstehen. Von der Projekt-ToDo-Liste oder der Featurelist kann ein Eintrag in das Backlog erfolgen, wenn es denn so weit ist, dass die Sache bearbeitet werden soll.

Der Pascal-Editor hat bezüglich der Unit-Analyse mehr Möglichkeiten, daher auch alle Inhalte der Dateien durchforstet und bestimmte Informationen sammelt. Daher kann dieser auch Units erfassen oder öffnen, die zwar nicht zum Projekt gehören (sprich in der DPR-Datei erfasst sind), aber über die Suchpfad-Einträge gefunden werden, siehe anliegenden Screenshot (der Dialog wird mit dem Schalter mit dem kleinen blauen "i" aufgerufen. Das könnte man erweitern und z.B. in die Zwischenablage kopieren oder als Datei speichern.

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1512789)

Zitat:

ob die augenscheinlich erfassten Daten zum Delphi-Projekt ausreichen oder ob was fehlt?

Information über erforderliche Tools, also externe Projekte wie DLLs aber auch Graphik Dateien. Für meine Icons verwende ich z.b. Affinity Designer, die jeweiligen Quelldateien würde ich gerne verlinken.

Das kannst Du in der Ansicht "Tools" (entsprechende Liste) verwalten.

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1512788)

Zitat:

Sollte ich noch eine "How-To" Liste hinzufügen, wo man Tipps zur Programmentwicklung verwalten kann?

Ich würde eher an eine allgemeine Liste denken. Hier sollten aber auch binäre Daten verwaltbar sein, zumindest aber jeweils ein ZIP zugeordnet sein. Z.b. um einen Privat Key abzuspeichern, Passwörter für den Server etc. Idealerweise sollte das alles zumindest mit einem Masterpasswort gesichert sein.

Ja, man kann die Datei auch durch ein Passwort schützen, macht auch Sinn, da ja hier auch Lizenzdaten, etc. erfasst werden sollen.