Einbinden von Units unterbinden

[EWeiss]

Ich habe 4 Suchpfade die addiert werden.

1. ..\KVideoPlayer64\DirectX9
2. ..\KVideoPlayer64\DSPack
3. ..\KVideoPlayer64\EVMRPlayer
4. ..\KVideoPlayer64\GDIP

Im ersten werden die DirectX Header hinzugefügt.

Im zweiten das DSPack.

Mein Problem ist nun das vom DSPack die Header von Winapi.DirectShow9 und andere verwendet werden.
Das will ich aber nicht es sollen diese aus dem Suchpfad DirectX9 eingebunden werde.
Wie kann ich also unterbinden das die vom Pfad Rtl/win verwendet werden.

Warum wird der Mist aus dem Pfad Rtl/win verwendet wenn ich doch DirectX9 als Suchpfad addiert habe.
Es wird quasi alles durcheinander geworfen.

gruss

[KodeZwerg]

Besteht die Möglichkeit DSpack zu editieren, und zwar so?

Delphi-Quellcode:

Uses IrgendEineDirectXUnit in 'C:\blabla\NutzeUnitX.pas';

Ps:
Wenn Du so alle DX-Units in der DPR deklarierst, sollten auch diese genommen werden so weit ich mich erinnern kann.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1413535)

Besteht die Möglichkeit DSpack zu editieren, und zwar so?

Delphi-Quellcode:

Uses IrgendEineDirectXUnit in 'C:\blabla\NutzeUnitX.pas';

Ps:
Wenn Du so alle DX-Units in der DPR deklarierst, sollten auch diese genommen werden so weit ich mich erinnern kann.

Nee so was mache ich nicht! :)

Das Problem ist generell die Header werden durcheinander gewürfelt.
Einmal werden diese vom Suchpfad verwendet und dann wieder vom "rtl/win"

Helfe mir jetzt damit das ich den Suchpfad entferne und die Units direkt zum Projekt addiere.
Was für ein Schmarrn..

gruss

[hoika]

Hallo,

Zitat:

Helfe mir jetzt damit das ich den Suchpfad entferne und die Units direkt zum Projekt addiere.

Das wäre jetzt auch meine Empfehlung gewesen.
DPR-Suchpfade haben Vorrang.

[KodeZwerg]

Also wenn Du das Alias so wie ich zeigte in der DPR aufbaust, sollten im Kompilat auch nur diese enthalten sein.
So mach ich es auch ab und zu bei Namen die Doppelt sind wo ich sicherstellen möchte das Unit aus PfadX fürs Projekt genommen wird.

edit
Huch, da kam gar kein roter Text, sorry.

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1413538)

Hallo,

Zitat:

Helfe mir jetzt damit das ich den Suchpfad entferne und die Units direkt zum Projekt addiere.

Das wäre jetzt auch meine Empfehlung gewesen.
DPR-Suchpfade haben Vorrang.

Scheinbar nicht denn das ist ja mein Problem!

Suchpfad addiert Header von Emba werden benutzt also aus dem Pfad "rtl/win"
Suchpfad entfernt Units direkt zum Projekt addiert, erst dann werden auch diese Units verwendet.
Oder was meinst du mit "DPR-Suchpfade"

Zitat:

Also wenn Du das Alias so wie ich zeigte in der DPR aufbaust, sollten im Kompilat auch nur diese enthalten sein.

Hallo hast du gelesen das ich die Units nun direkt zum Projekt addiere ?
Was willst du mehr.

gruss

[TiGü]

Auch wenn du es nicht lesen magst:
Am nachhaltigsten und zukunftssichersten wäre dennoch, wenn du auch die Winapi.Direct...-Header direkt verwendest.
Die paar Typen und Konstanten die da eventuell noch fehlen kann man in einer eigenen neuen Unit reinkopieren.
Es ist ein bisschen Umstellung, aber langfristig fährst du so besser.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1413548)

Auch wenn du es nicht lesen magst:

Wer sagt das?

Es bringt mir keinen Vorteil wenn diese fehlerhaft sind.
Deshalb meine Entscheidung.. in den von mir privat angelegten Headern kann ich wenigstens editieren um die Fehler zu beseitigen wenn gefunden.
Was ich nicht verstehe. Warum hat der Pfad von Emba Vorrang gegenüber meinen angelegten Suchpfad.
Wofür ist der wenn sich der von Emba zwischen schummelt.

Bevor die Frage aufkommt woran ich das erkenne das sie Fehlerhaft sind!
Die 32Bit Anwendung läuft einwandfrei mit den 32Bit Headern von DirectX.
Die 64Bit Anwendung nicht trotz eingebundenen 64Bit DirectX Headern von Emba oder denen von mir.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1413549)

Es bringt mir keinen Vorteil wenn diese fehlerhaft sind.

Aber im Direct3D9-Thread war die Problemursache doch genau verkehrt rum?
Die Winapi.Direct3D9-Unit war ok und die eigene nicht.

Zitat:

Zitat von EWeiss (Beitrag 1413549)

Was ich nicht verstehe. Warum hat der Pfad von Emba Vorrang gegenüber meinen angelegten Suchpfad.
Wofür ist der wenn sich der von Emba zwischen schummelt.

Ist möglicherweise der Suchpfad zu den Sourcen von Emba einfach weiter vorne in der Liste?
Wie weiter oben beschrieben ist die Verwendung durch in das Projekt ziehen (so dass die Units in der DPR) auftauchen der sinnvollste Weg.
Ich rate dennoch zur Umstellung, weil die DSPack-Version (je nach Quelle) sich wahrscheinlich darauf verlässt, dass die Emba-Header-Konvertierungen genommen werden.
So heißt es bspw. in diesem Fork (https://github.com/micha137/dspack-c...-for-delphinus), dass man die Emba eigenen Units nehmen soll.

Zitat:

DirectX headers are now provided with Delphi
don't use these units anymore

ganz unten stehts: https://github.com/micha137/dspack-c...r/src/DirectX9

[EWeiss]

Zitat:

Aber im Direct3D9-Thread war die Problemursache doch genau verkehrt rum?
Die Winapi.Direct3D9-Unit war ok und die eigene nicht.

Da ging es auch um VRM9 und EVR diese verwenden IDirect3DSurface9
VRM7 aber DirectDraw, m_pDDSurface: IDirectDrawSurface7;

VMR9 und EVR funktionieren ja auch nach dem verweis auf die Header von Emba.
VMR7 hingegen nicht trotz 64Bit Header.

gruss

[Schokohase]

Also unter 10.2 Tokyo (gerade getestet) haben die Suchpfade im Projekt Vorrang vor den globalen Suchpfaden.

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1413552)

Also unter 10.2 Tokyo (gerade getestet) haben die Suchpfade im Projekt Vorrang vor den globalen Suchpfaden.

Reden wir aneinander vorbei?
OK dann ein Shot!

Es soll die DirectDraw .pas aus dem Suchpfad (..\KVideoPlayer64\DirectX9) verwendet werden NICHT die WinApi.DirectDraw!
Bedenke DirectDraw.pas wurde nicht zum Projekt addiert nur über den vor eingestellten Suchpfad.
Wenn ich nun bei DirectDraw (Menu.. Datei beim Cursor öffnen) anklicke wird Winapi.DirectDraw geöffnet und das ist definitiv falsch!

gruss

[Uwe Raabe]

Kann es sein, daß das Problem nur dann auftritt, wenn bei den Compiler-Optionen das "Mit Debug-DCUs" aktiviert ist? In dem Fall werden die Debug-DCU Pfade womöglich vor die Projekt-Suchpfade gestellt.

Ich habe mal bei StackOverflow etwas zu dem Thema geschrieben. Ist zwar schon eine Weile her, aber ist womöglich immer noch relevant: Managing very large codebases in Delphi using a Library of Debug and Regular DCUs I built myself

Es ist allerdings auch so, daß nicht die Delphi Source-Pfade (z.B. rtl\win) im Suchpfad stehen, sondern nur das der Plattform entsprechende lib-Verzeichnis - zumindest in einer Standard-Installation ist das so.

[EWeiss]

Zitat:

"Mit Debug-DCUs" aktiviert ist?

Ist false.. bei Release und Debug
Also nach meinem Verständnis wenn man schon einen Suchpfad angibt dann sollte dieser Vorrang vor den von Emba haben.
Ansonsten macht es keinen Sinn überhaupt Suchpfade anzulegen..

PS:
Ich habe auch schon die Reihenfolge geändert also
den Pfad (..\KVideoPlayer64\DirectX9) an erster stelle, ändert aber nichts an dem Problem.

Sorry.. zum Schluss noch es steht DirectDraw als unit in den Uses nicht Winapi.DirectDraw

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1413555)

Also nach meinem Verständnis wenn man schon einen Suchpfad angibt dann sollte dieser Vorrang vor den von Emba haben.

Das sollte eigentlich auch so sein.

Kannst du mal aus dem Meldungsfenster die Befehlszeile des Compilers hier zeigen. Dort sollte ja der tatsächlich verwendete Suchpfad zu erkennen sein.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1413556)

Zitat:

Zitat von EWeiss (Beitrag 1413555)

Also nach meinem Verständnis wenn man schon einen Suchpfad angibt dann sollte dieser Vorrang vor den von Emba haben.

Das sollte eigentlich auch so sein.

Kannst du mal aus dem Meldungsfenster die Befehlszeile des Compilers hier zeigen. Dort sollte ja der tatsächlich verwendete Suchpfad zu erkennen sein.

Ja über PN das sind private Daten..

Hier ein kleiner Ausschnitt.

Zitat:

release\DE ";..\KVideoPlayer64\DirectX9;..\KVideoPlayer64 \EVM RPlayer;..\KVideoPlayer64\DSPack

PS:
Anderes Problem..

Delphi-Quellcode:

Uses DirectShow9, GDIPAPI, GDIPOBJ;

DirectShow9 öffnet Winapi.DirectShow9
GDIPAPI öffnet Winapi.GDIPAPI
GDIPOBJ öffnet die korrekte Unit.

Was soll das?

gruss

[Delphi.Narium]

Zitat:

Zitat von EWeiss (Beitrag 1413558)

Hier ein kleiner Ausschnitt.

Zitat:

release\DE ";..\KVideoPlayer64\DirectX9;..\KVideoPlayer64 \EVM RPlayer;..\KVideoPlayer64\DSPack

Wenn ich solche Probleme habe, sorge ich dafür, dass "meine" Pfade in dieser Liste am Anfang zugefügt werden und nicht, wie von der IDE üblich, ans Ende. Man muss dann halt, wenn man über die IDE Pfade hinzufügt, diese nochmal in der Eingabe "rumkopieren". Meist klappt das dann.

[EWeiss]

Zitat:

Zitat von Delphi.Narium (Beitrag 1413560)

Zitat:

Zitat von EWeiss (Beitrag 1413558)

Hier ein kleiner Ausschnitt.

Zitat:

release\DE ";..\KVideoPlayer64\DirectX9;..\KVideoPlayer64 \EVM RPlayer;..\KVideoPlayer64\DSPack

Wenn ich solche Probleme habe, sorge ich dafür, dass "meine" Pfade in dieser Liste am Anfang zugefügt werden und nicht, wie von der IDE üblich, ans Ende. Man muss dann halt, wenn man über die IDE Pfade hinzufügt, diese nochmal in der Eingabe "rumkopieren". Meist klappt das dann.

Es geht nicht um einen Workaround (den suche ich nicht) es MUSS auf normalem Wege funktionieren!
bzw. Den habe ich ja wenn ich die Units direkt zum Projekt addiere aber das ist NICHT der sinn der Sache.

Siehe! Nochmals..

Anderes Problem..
Uses DirectShow9, GDIPAPI, GDIPOBJ;

DirectShow9 öffnet Winapi.DirectShow9
GDIPAPI öffnet Winapi.GDIPAPI
GDIPOBJ öffnet die korrekte Unit.

gruss

[hoika]

Hallo,

Zitat:

Bedenke DirectDraw.pas wurde nicht zum Projekt addiert nur über den vor eingestellten Suchpfad.

das meinte ich aber.
Die Pfade, die hinter der Pas in der DPR stehen, haben meines Wissens immer Vorrang.
Ist nicht schön, aber was solls.

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1413562)

Hallo,

Zitat:

Bedenke DirectDraw.pas wurde nicht zum Projekt addiert nur über den vor eingestellten Suchpfad.

das meinte ich aber.
Die Pfade, die hinter der Pas in der DPR stehen, haben meines Wissens immer Vorrang.
Ist nicht schön, aber was solls.

Ja das ist mein Workaround.. aber ich will es nicht.

Auch die Suchpfade müssen Vorrang haben unabhängig davon ob ich die Units direkt zum Projekt addiere.
Haben sie aber nicht.
Es gibt einen Grund warum man nicht alle Dateien zum Projekt addieren möchte.
Meiner ist es sollen nur Master Units direkt addiert werden nicht untergeordnete.

Meiner Ansicht ist das dann ein BUG in der IDE..
Man weis ja gar nicht welche Unit nun beim Debuggen berücksichtigt wird wenn hier falsche Units geöffnet werden. :wall:

gruss

[Schokohase]

Trotzdem du ein Minimal-Beispiel-Verweigerer bist habe ich dir mal ein Minimal-Beispiel angehängt.

ACHTUNG: Delphi 10.2 Tokyo

Das Projekt hat neben den Konfigurationen Debug und Release auch noch RoutedDirectX9 und RoutedDirectX9mod.

Bei RoutedDirectX9 wird das Verzeichnis .\DirectX9 in den Projekt-Suchpfad aufgenommen.
Bei RoutedDirectX9mod wird das Verzeichnis .\DirectX9mod in den Projekt-Suchpfad aufgenommen.

Das Projekt gibt lediglich den GUID-String der DirectDraw Konstanten

Delphi-Quellcode:

CLSID_DirectDraw

aus, die im Original

Delphi-Quellcode:

'{D7B70EE0-4340-11CF-B063-0020AFC2CD35}'

ist.
In meiner DirectDraw Unit ist der Wert auf

Delphi-Quellcode:

'{11111111-1111-1111-1111-0020AFC2CD35}'

festgelegt.

In dem Beispiel-Projekt kann man nur bei der Konfiguration RoutedDirectX9mod diesen Wert sehen, was bedeutet dort wird tatsächlich die untergeschobene DirectDraw Unit verwendet.

PS: Das war der entscheidende Hinweis

Zitat:

Zitat von EWeiss (Beitrag 1413553)

Es soll die DirectDraw.pas aus dem Suchpfad (..\KVideoPlayer64\DirectX9) verwendet werden NICHT die WinApi.DirectDraw!

[EWeiss]

Zitat:

was bedeutet dort wird tatsächlich die untergeschobene DirectDraw Unit verwendet.

Du verstehst es immer noch nicht .. Sorry.
Es wird die Unit Winapi.DirectDraw geöffnet unabhängig davon das tatsächlich die untergeschobene DirectDraw Unit verwendet wird.

Verwende das Menu Cursor auf (unit SearchPathPriority) DirectDraw. Datei beim Cursor öffnen.
Was wird geöffnet?

Bei mir ist es die WinApi.DirectDraw es muss aber deine untergeschobene DirectDraw Unit sein.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1413558)

Ja über PN das sind private Daten..

Hier ein kleiner Ausschnitt.

Zitat:

release\DE ";..\KVideoPlayer64\DirectX9;..\KVideoPlayer64 \EVM RPlayer;..\KVideoPlayer64\DSPack

Die Befehlszeile entspricht in etwa dem, was ich in der StackOverflow Antwort geschrieben habe. Hier ist es die Spracheinstellung DE, die für eine falsche Sortierung der Suchpfade sorgt. Die Änderung der CodeGear.Delphi.Targets gemäß der dortigen Beschreibung sollte das Problem lösen.

Du kannst das vorab ja mal ausprobieren, indem du in Delphi unter Tools - Umgebungsoptionen - Umgebungsvariablen die LANDIR Variable überschreibst und statt des DE einen Leerstring einträgst. Damit sollten die sprachabhängigen Suchpfade nicht mehr in der Befehlszeile auftauchen. Allerdings verwendet dein Programm dann halt die englischen Ressourcen, aber es ist ja nur zum Testen. Das ändern der Targets-Datei löst das Problem dann dauerhaft.

Wer mag, kann ja für diesen QP-Eintrag voten: Wrong order of search pathes presented to compiler
Vielleicht muss ich dann irgendwann diese Anpassung nicht bei jeder Delphi-Installation wiederholen.

[Schokohase]

Probiere es aus und du wirst überraschst sein, wie unterschiedlich sich doch die IDE und der Compiler verhalten.

Ich muss zugeben, dass ich zunächst auch erst darauf reingefallen bin, aber beim Ausführen war es doch so wie gedacht.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1413567)

Zitat:

Zitat von EWeiss (Beitrag 1413558)

Ja über PN das sind private Daten..

Hier ein kleiner Ausschnitt.

Zitat:

release\DE ";..\KVideoPlayer64\DirectX9;..\KVideoPlayer64 \EVM RPlayer;..\KVideoPlayer64\DSPack

Die Befehlszeile entspricht in etwa dem, was ich in der StackOverflow Antwort geschrieben habe. Hier ist es die Spracheinstellung DE, die für eine falsche Sortierung der Suchpfade sorgt. Die Änderung der CodeGear.Delphi.Targets gemäß der dortigen Beschreibung sollte das Problem lösen.

Du kannst das vorab ja mal ausprobieren, indem du in Delphi unter Tools - Umgebungsoptionen - Umgebungsvariablen die LANDIR Variable überschreibst und statt des DE einen Leerstring einträgst. Damit sollten die sprachabhängigen Suchpfade nicht mehr in der Befehlszeile auftauchen. Allerdings verwendet dein Programm dann halt die englischen Ressourcen, aber es ist ja nur zum Testen. Das ändern der Targets-Datei löst das Problem dann dauerhaft.

Wer mag, kann ja für diesen QP-Eintrag voten: Wrong order of search pathes presented to compiler
Vielleicht muss ich dann irgendwann diese Anpassung nicht bei jeder Delphi-Installation wiederholen.

Uwe Danke für den Tip.

Ich habe es damit behoben das ich die Dateien zum Projekt addiert habe.
Es geht aber nicht um einen Workaround sondern darum das es ein Fehler in der IDE ist..
Ich denke das sollte gemeldet werden.. ich kann es leider nicht!

gruss

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1413569)

Probiere es aus und du wirst überraschst sein, wie unterschiedlich sich doch die IDE und der Compiler verhalten.
Ich muss zugeben, dass ich zunächst auch erst darauf reingefallen bin, aber beim Ausführen war es doch so wie gedacht.

Hallo?
Ich habe es ausprobiert sonst würde ich es nicht posten.
Dein Projekt öffnet WinApi.DirectDraw.
Ich hoffe du kannst ein Bild lesen ?

PS:
Bei mir hingegen steht DirectDraw und wird mit Winapi.DirectDraw geöffnet.

gruss

[Schokohase]

@Uwe Raabe

Das ist aber nicht die Ursache für dieses Problem.

Bei Unit-Gültigkeitsbereichsnamen ist u.a. der Eintrag Winapi enthalten.
Wird jetzt die Unit DirectDraw über den Suchpfad gesucht, dann wird erst nach Units mit dem Namen Winapi.DirectDraw gesucht und ja auch gefunden, die aber gar nicht gewollt sind. Erst wenn keine Winapi.DirectDraw gefunden würde, dann würde nur nach DirectDraw gesucht.

Benennt man die modifizierte Unit aber nach Winapi.DirectDraw um, dann wird diese auch gefunden und verwendet.

[Schokohase]

@Emil

Du sollst das Beispiel-Projekt in der Konfiguration RoutedDirectX9mod erzeugen und ausführen. Dann - und nur dann - wirst du sehen, dass die DirectDraw aus dem Ordner .\DirectX9mod verwendet wurde.

Nochmal: Nur beim Ausführen wirst du es sehen!
Nochmal: Nur beim Ausführen wirst du es sehen! - Nicht in der IDE

Zeigst du mir zum Beweis jetzt wieder Screenshots von der IDE ... dann lies es bitte nochmal

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1413575)

@Emil
Ziegst du mir zum Beweis Screenshots von der IDE ... dann lies es bitte nochmal

Ich verstehe was du meinst.
Aber genau darum geht es mir um nichts anderes.

Mein Unverständnis ist folgendes..

Wenn ich debugge und möchte eine Unit aus meinem Pfad öffnen was tue ich? Richtig ich klicke auf den Namespace und sage Datei beim Cursor öffnen.

Nun und du glaubst das ist normal wenn dann die falsche geöffnet wird?
Darum geht es mir um nichts anderes.. welche Unit letztendlich wirklich beim Kompilieren verwendet wird mag mal dahingestellt sein.
Wenn ich Anfänger wäre dann würde ich schon alleine daran verzweifeln weil immer die FALSCHE Unit geöffnet wird.
Stell dir vor man achtet nicht darauf und fängt dann an diese Unit zu bearbeiten.

gruss

[Schokohase]

@Emil

Da bin ich ganz nah bei dir.

Ja, die IDE verhält sich da sehr seltsam und das gehört behoben.

[EWeiss]

Zitat:

Zitat von Schokohase (Beitrag 1413579)

@Emil

Da bin ich ganz nah bei dir.

Ja, die IDE verhält sich da sehr seltsam und das gehört behoben.

OK!

Das ist mein Problem mit dem ich bzw.. Anfänger dann zu kämpfen haben.
Wie gesagt man kann das ändern indem man wie du sagst die Eigene Unit umbenennt bsp. WinApi.DirectDraw.
Aber das Problem ist dann man verwendet System spezifische Unit Namen
ob das so gut rüber kommt und dann nicht auch wieder zu Konflikten führt habe ich nicht getestet.

Ansonsten gebe ich dir recht es wird beim Kompilieren die richtige Unit verwendet..
Es ist aber definitiv die Falsche die beim klick auf Datei öffnen zur Bearbeitung geöffnet wird.

gruss

[Uwe Raabe]

Zitat:

Zitat von Schokohase (Beitrag 1413574)

Bei Unit-Gültigkeitsbereichsnamen ist u.a. der Eintrag Winapi enthalten.
Wird jetzt die Unit DirectDraw über den Suchpfad gesucht, dann wird erst nach Units mit dem Namen Winapi.DirectDraw gesucht und ja auch gefunden, die aber gar nicht gewollt sind. Erst wenn keine Winapi.DirectDraw gefunden würde, dann würde nur nach DirectDraw gesucht.

Nein, das stimmt so nicht. Steht in der uses ein DirectDraw, dann wird erst im Projektverzeichnis und dann in den Suchpfaden nach DirectDraw gesucht. Erst wenn dabei keine Unit gefunden wurde, werden die Unit-Gültigkeitsbereichsnamen durchprobiert (siehe beiliegendes Projekt).

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1413585)

Zitat:

Zitat von Schokohase (Beitrag 1413574)

Bei Unit-Gültigkeitsbereichsnamen ist u.a. der Eintrag Winapi enthalten.
Wird jetzt die Unit DirectDraw über den Suchpfad gesucht, dann wird erst nach Units mit dem Namen Winapi.DirectDraw gesucht und ja auch gefunden, die aber gar nicht gewollt sind. Erst wenn keine Winapi.DirectDraw gefunden würde, dann würde nur nach DirectDraw gesucht.

Nein, das stimmt so nicht. Steht in der uses ein DirectDraw, dann wird erst im Projektverzeichnis und dann in den Suchpfaden nach DirectDraw gesucht. Erst wenn dabei keine Unit gefunden wurde, werden die Unit-Gültigkeitsbereichsnamen durchprobiert (siehe beiliegendes Projekt).

Was macht das Projekt?
Bei mir nichts, was vergessen?
Mal davon abgesehen das auch hier die falsche zu bearbeitende Datei geöffnet wird.

Delphi-Quellcode:

program TestProject;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  DirectDraw;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1413586)

Was macht das Projekt?
Bei mir nichts, was vergessen?

Es macht wirklich nichts, aber im Meldungsfenster sollte die Meldung "Hurz" auftauchen, wenn die DirectDraw aus dem Subfolder compiliert wird. Würde die WinApi.DirectDraw verwendet, käme die Meldung nicht.

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1413586)

Mal davon abgesehen das auch hier die falsche zu bearbeitende Datei geöffnet wird.

Interessant ist hierbei, daß zwar bei "Datei beim Cursor öffnen" die Winapi.DirectDraw geöffnet wird, bei "Deklaration suchen" oder mit Strg-Click jedoch die korrekte DirectDraw.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1413588)

Zitat:

Zitat von EWeiss (Beitrag 1413586)

Was macht das Projekt?
Bei mir nichts, was vergessen?

Es macht wirklich nichts, aber im Meldungsfenster sollte die Meldung "Hurz" auftauchen, wenn die DirectDraw aus dem Subfolder compiliert wird. Würde die WinApi.DirectDraw verwendet, käme die Meldung nicht.

Das wird wohl so sein.

Aber es geht nicht um das Kompilieren welche Datei da genommen wird.
Das hat seine Richtigkeit.
Es geht mir um die zu Bearbeitende Datei.. welche mit rechtsklick auf Namespace (Datei beim Cursor öffnen) geöffnet wird.
Es ist nicht diese die du im Suchpfad angegeben hast.

Zitat:

Interessant ist hierbei, daß zwar bei "Datei beim Cursor öffnen" die Winapi.DirectDraw geöffnet wird, bei "Deklaration suchen" oder mit Strg-Click jedoch die korrekte DirectDraw.

Nun die frage ist würde dich das als Anfänger nicht auch sehr verwundern?
Für mich ist das ein ganz klarer BUG innerhalb der IDE.

Zitat:

"Deklaration suchen" oder mit Strg-Click jedoch die korrekte DirectDraw.

Schon seltsam das ist korrekt! OK! Fails in der IDE das ist Fakt!

PS:
Hat lange gedauert bis man verstanden hat was ich meinte ;)

gruss

[TiGü]

In der Zeit hätte ich ja schon dreimal den "eigenen" zu verwendenden Units einen Präfix verpasst und alles per Suchen&Ersetzen gefixt.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1413593)

In der Zeit hätte ich ja schon dreimal den "eigenen" zu verwendenden Units einen Präfix verpasst und alles per Suchen&Ersetzen gefixt.

Jo der Fehler ist aber dann immer noch vorhanden egal was du unternommen hättest.
Die Fehler in der IDE scheinen einige Leute nicht wirklich zu interessieren.
Klar kann man alles zurecht pfriemeln ist aber nicht der Sinn der Sache.

Meine Verwirrung entstand ja wegen dieser Probleme.

Zitat:

Mein Problem ist nun das vom DSPack die Header von Winapi.DirectShow9 und andere verwendet werden.
Das will ich aber nicht es sollen diese aus dem Suchpfad DirectX9 eingebunden werde.
Wie kann ich also unterbinden das die vom Pfad Rtl/win verwendet werden.

Warum wird der Mist aus dem Pfad Rtl/win verwendet wenn ich doch DirectX9 als Suchpfad addiert habe.
Es wird quasi alles durcheinander geworfen.

Das trotzdem die richtigen Dateien beim kompilieren verwendet werden sollte jetzt klar sein.
Destotrotz wird die falsche Datei zur Bearbeitung geöffnet.

Nebenbei..

Zitat:

"Deklaration suchen" oder mit Strg-Click jedoch die korrekte DirectDraw.

Haben bei mir mitunter überhaupt keine Auswirkung.. es passiert NIX wenn ich einen der beiden varianten verwende.
Es wird der Ausgelastete Cursor gezeigt das war es dann schon.

Für mich ist das Thema erledigt.. Danke! Das Ergebnis. Fehler in der IDE.

gruss

[Rolf Frei]

Hast du deine Units im "Browsing Path" (4. Eingabe in den Umgebungsoption) hinterelegt? Dieser ist dafür da, Dateien im Editor zu finden. Der Search Path zeigt ja normalerweise auf eine Dir mit den dcu's (lib). Der Browsing Path hat für den Editor immer Vorrang.

Ausserdem würde ich dir raten, deine Units gleich zu benennen wie die von Delphi. So hast du auch keine Probleme mit Sourcen, die WinApi.X in der uses drin haben. Diese nutzen dann auch deine Versionen. Wenn deine Units aber ohne WinApi vorliegen, wird von allen Untis, in denen Winapi.X steht die Delphi Version verwendet und nicht deine.

[EWeiss]

Wie ich schon sagte ich suche keinen Workaround den habe ich.
Das Problem muss in der IDE gefixt werden.
Mehr gibt es da nicht mehr zu sagen.

Und nein ich werde meine Units nicht gleich System Units benennen.
Ich bzw. Der User soll diese unterscheiden können.

gruss