Bedingte Compilierung

[himitsu]

Dieses Leerzeichen stört notfalls auch nicht. (bei einem Leerzeichen zwischen { und $ wäre es dagegen was Anderes)

[Michael II]

Danke himitsu und Dalai für Eure Antworten!

Danke Dalai für den Hinweis punkto Leerzeichen. Du fragst Absicht oder Versehen? Spock würde wohl mit Ja antworten .
Wie himitsu schreibt: Das Leerzeichen an dieser Stelle wird vom Compiler nicht beachtet. [Ich hab's aber trotzdem nun weggeputzt...]

Zu meinem Problem: Ich habe das Projekt nun in Seattle geladen und gestartet und dort klappt es.
Ich habe fastmm4 entfernt, aber nach einiger Zeit war das Problem auch ohne fastmm4 zurück: Wenn ich Start(F9) drücke, dann werden 59 Module geladen und dann ein weiteres geladen und gleich wieder entladen.
Leider sehe ich bei diesem Modul nicht, wie es heisst. Da scheint es irgend ein Pointer Problem zu geben; mal ist im Ereignisprotokoll der Modul Name leer, dann wird MZP angezeigt und dann wieder ������������������� [und viele andere Dinge]
:

So sieht es im Ereignisprotokoll aus:

Module Load: srvcli.dll. No Debug Info. Base Address: $6CFD0000. Process Jass.exe (12336)
Module Load: . No Debug Info. Base Address: $03710000. Process Jass.exe (12336)
Module Unload: . Process Jass.exe (12336)

oder so:
Modullade-Haltepunkt bei $65054A30: Modul srvcli.dll geladen. Prozess Jass.exe (10116)
Modul laden: MZP. Ohne Debug-Infos. Basisadresse: $03740000. Prozess Jass.exe (10116)
Modul entladen: MZP. Prozess Jass.exe (10116)

oder so:
Modul laden: srvcli.dll. Ohne Debug-Infos. Basisadresse: $65050000. Prozess Jass.exe (3144)
Modul laden: �������������������
 
!%368:<. Ohne Debug-Infos. Basisadresse: $05030000.
Prozess Jass.exe (3144)
Modul entladen: �������������������
 
!%368:<.


Wenn nach dem Start(F9) Delphi Berlin Update 1 hängt, dann wird in der Ereignisanzeige nur noch das Laden von srvcli.dll angezeigt. Danach muss Delphi jeweils neu gestartet werden.

Ich merke, dass ich hier punkto Wissen an meine Grenzen stosse... hat jemand einen Tipp, wie ich herausfinden kann, wie das Modul heisst, welches zu diesem Problem führt? Und wie ich das Laden verhindern kann? [Bei Seattle ist der Name des Moduls in der Ereignisanzeige immer leer. Wahrscheinlich klappt es deshalb dort immer.]



Besten Dank.

Gruss
Michael

[Dalai]

Überempfindlicher Virenscanner (vielleicht mit integrierter Sandbox)?

Grüße
Dalai

[Michael II]

Hallo dalai

danke für deinen Hinweis. Nun das compilierte Programm funktioniert ja [also wahrscheinlich kein Scanner Problem], einfach beim Debuggen schmiert die Sache immer wieder ab (Delphi schmiert ab [Fehlermeldung einsenden], oder Delphi läuft zwar noch meldet aber, ich müsse meine Arbeit speichern und Delphi neu starten oder es wird angezeigt Assertion failure:"!"UNKNOWN evaluator type "" in ..\win32src\DBKIMPL.CPP at line 4017).


Ich habe nun dank ProcMon auch gesehen, an welcher Stelle im Code ab und zu alles stehen bleibt: Beim Setzen einer .lnk Datei auf dem Desktop. Wieso es passiert, weiss ich allerdings nicht.

Da mein eigener Code etwas "aufgeblasen" ist, habe ich nach einem anderen gesucht, bei welchem das Problem auch auftritt und bei about gefunden (Code unten).

Wenn ich den Code unten lade, das Programm erzeuge, einen Haltepunkt in der Zeile
IPFile.Save(PWChar(LinkName), false) ;
setze und dann starte(F9), dann sehe ich, dass bei der Ausführung der obigen Zeile ein Modul geladen und wieder entladen wird. Mal ist der Name des Moduls leer (zum Beispiel immer bei Seattle) und mal wird irgend ein String angezeigt. Und ab und zu schmiert es wie eingangs erwähnt ab.

Auf meinem Rechner (Win10 Anni Update) passiert dies nur mit Delphi Berlin Update. Vielleicht hat ja ein delphipraxis Mensch einen Tipp, wie man es so macht, dass es auch mit DBUp klappt.



(* uses ShlObj, ActiveX, ComObj; *)

procedure lnk_auf_desktop;
var IObject : IUnknown;
ISLink : IShellLink;
IPFile : IPersistFile;
PIDL : PItemIDList;
InFolder : array[0..MAX_PATH] of Char;
TargetName : String;
LinkName : WideString;
begin
TargetName := Application.ExeName; {
Use TargetName:=ParamStr(0) which returns the path and file name of the
executing program to create a link to your Application}
IObject := CreateComObject(CLSID_ShellLink) ;
ISLink := IObject as IShellLink;
IPFile := IObject as IPersistFile;
with ISLink do
begin
SetPath(pChar(TargetName)) ;
SetWorkingDirectory(pChar(ExtractFilePath(TargetNa me))) ;
end; // if we want to place a link on the Desktop
SHGetSpecialFolderLocation(0, CSIDL_DESKTOPDIRECTORY, PIDL) ;
SHGetPathFromIDList(PIDL, InFolder) ;
{ or if we want a link to appear in
some other, not-so-special, folder:
InFolder := 'c:\SomeFolder' }
LinkName := InFolder + '\Delphi Created Link.lnk';
IPFile.Save(PWChar(LinkName), false) ;
end;

Quelle: http://delphi.about.com/od/windowssh...create_lnk.htm

Gruss
Michael

[Dalai]

Mmh, mein Code zum Speichern von Verknüpfungen sieht komplett anders aus. Ich arbeite mit CoCreateInstance, jeder wichtige Aufruf ist zusätzlich mit OleCheck abgesichert, so dass man sofort eine Exception bekommt, wenn etwas nicht passt. Leider habe ich momentan keine Zeit, meinen Code entsprechend aufzubereiten, um ihn zu posten. Insofern kann ich derzeit nur Hilfe zur Selbsthilfe geben und empfehlen, anderen Code zum Speichern von LNKs zu suchen.

Grüße
Dalai

[Michael II]

Hallo Dalai

danke für deine Antwort. Mein Code sieht auch abgesicherter aus [ich lasse mir bei Exceptions eine eMail senden mit Infos - das hilft sehr...], ich wollte hier halt nur den Kern des Problems posten, damit vielleicht jemand mit Berlin Up dies testen kann.

Der Code funktioniert ja [der Link wird korrekt erstellt], aber beim Debuggen taucht eben das beschriebene Problem auf.

Und ich frage mich wieso. Ist das ein Bug im Code (es wird keine Exception ausgelöst) oder ein Bug in Delphi?

Wegen Alternative: Ich bin immer etwas vorsichtig punkto Änderungen, wenn es draussen in der Welt ja eigentlich klappt. [Bis heute auf >40'000 Compis installiert und auf mehreren hundert Compis hunderte Updates eingespielt; und keine Exception-Meldung erhalten, weder vom Programm noch von Usern.] Wenn der Code aber problematisch ist, dann werde ich hier vielleicht doch was anpassen.

Viel Sonne wünsch .

Gruss
M

[Michael II]

Hallo Dalai

nur noch kurz: Du findest auf der microsoft Seite den "genau gleichen" Code (halt nicht in Delphi ).

Du schreibst, dass du es anders machst. Wenn du es in etwa so machst wie im Code unten: Es funktioniert auch so, der Link wird korrekt erstellt, aber es taucht das genau gleiche Problem beim Debuggen auf; natürlich an genau der gleichen Stelle.

Gruss
M

Delphi-Quellcode:

uses ShlObj, ActiveX, ComObj;

function CreateLinkFile(AFilename, ALinkfile, ADescription: string) : Boolean;
var
  pShellLinkW : IShellLinkW;
  pPersistFile : IPersistFile;
begin
  result:=false;
  if SUCCEEDED(CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_inPROC_SERVER, IID_IShellLinkW, pShellLinkW)) then
  begin
    pShellLinkW.SetPath(PWideChar(AFilename));
    pShellLinkW.SetDescription(PWideChar(ADescription));
    pShellLinkW.SetWorkingDirectory(PWideChar(ExtractFilePath(AFilename)));
    if SUCCEEDED(pShellLinkW.QueryInterface(IPersistFile, pPersistFile)) then
    begin
      pPersistFile.Save(PWideChar(ALinkFile), true);
    end;
  end;
end;