Rückgabe von hModul ist fehlerhaft

[EWeiss]

Eigentlich funktioniert das..

Code:

HMODULE gdiplib() {
    static HMODULE hGdip;
    if (hGdip == 0) { hGdip = LoadLibrary(L"GDIPLUS"); }
    return hGdip;
}

aber wenn ich diese Funktion aufrufe um einen Font zu erstellen.

Code:

GdipCreateFont(fontfam, (float)UseSize, 0, 2, TempFont);

Code:

long GdipCreateFont(IN LONG_PTR fontFamily, IN float emSize, IN long style, IN long unit, OUT LONG_PTR &font) {
    long nRet = -1; // Error
    font = 0;
    HMODULE hModule = gdiplib();
    if (hModule) {
        long_proc(LONG_PTR, float, long, long, LONG_PTR*);
        static zProc hProc;
        if (hProc == 0) { hProc = (zProc)GetProcAddress(hModule, "GdipCreateFont"); }
        if (hProc) { nRet = hProc(fontFamily, emSize, style, unit, &font); }
    }
    return nRet;
}

ist TempFont immer 0 weil das hModule den wert 0xfefefefe zurück gibt.

Zitat:

Vom Speicher kann nicht gelesen werden..

Ich finde den Fehler wieder mal nicht warum das fehl schlägt.
Warum gehen mir ständig die Handles verloren.

Unter Delphi habe ich mit solchen Problemen nicht zu kämpfen.

gruss

[hoika]

Hallo,
OUT LONG_PTR &font) {

Hm, das wäre jetzt ein Doppelpointer.

Reicht denn nicht
OUT LONG_long &font

oder
OUT LONG_PTR font) {

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1379175)

Hallo,
OUT LONG_PTR &font) {

Hm, das wäre jetzt ein Doppelpointer.

Reicht denn nicht
OUT LONG_long &font

oder
OUT LONG_PTR font) {

Es reicht das was von der API GdipCreateFont vorgegeben wird.

Code:

GpStatus WINGDIPAPI GdipCreateFont( GDIPCONST GpFontFamily *fontFamily, REAL emSize, INT style, Unit unit, GpFont **font )

Und hier wird nun mal ein Doppelpointer verlangt.

Das ist aber nicht mein Problem sondern das mir die Handles verloren gehen.

EDIT:
Es sieht so aus das VC++ extrem auf Speicherlecks reagiert das ist wohl auch der Grund warum dann von Speicher nicht gelesen werden kann.


gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1379180)

Es sieht so aus das VC++ extrem auf Speicherlecks reagiert das ist wohl auch der Grund warum dann von Speicher nicht gelesen werden kann.

Speicherlecks sollten hier kein Problem darstellen. Höchstens Buffer overflows.

Hat es btw einen bestimmten Grund, dass du die GDI+ dynamisch lädst?

Den NULL Check kannst du dir übrigens sparen. Statics werden eh nur einmalig initialisiert:

Code:

HMODULE gdiplib() 
{
    static HMODULE hGdip = LoadLibrary(L"GDIPLUS");
    return hGdip;
}

[hoika]

Hallo,
um noch mal auf die Ausgangsfrage zurückzukommen:

long GdipCreateFont(IN LONG_PTR fontFamily, IN float emSize, IN long style, IN long unit, OUT LONG_PTR &font) {
long nRet = -1; // Error
font = 0;
HMODULE hModule = gdiplib(); // ** //

// ** // hier ist jetzt hModule irgendwann nicht mehr der Wert, der ursprünglich in hGdip stand?
D.h. die static-Variable ist durch irgendwas überschrieben worden?

[EWeiss]

Zitat:

D.h. die static-Variable ist durch irgendwas überschrieben worden?

Hier schon..

Code:

HMODULE gdiplib() 
 {
     static HMODULE hGdip = LoadLibrary(L"GDIPLUS");
     return hGdip;
 }

der beträgt irgendwann 0xFEFEFEFEFE

EDIT:

Zitat:

Hat es btw einen bestimmten Grund, dass du die GDI+ dynamisch lädst?

Dazu möchte ich mich jetzt nicht äußern um böses Blut zu vermeiden. Das Internet liest mit!

gruss

[Fritzew]

Zitat:

der beträgt irgendwann 0xFEFEFEFEFE

Dann ist aber etwas ziemlich im argen. Irgendwo wird der Speicher überschrieben.
Da kann ich nur sagen "Viel Spass beim suchen":-D

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1379211)

Zitat:

der beträgt irgendwann 0xFEFEFEFEFE

Dann ist aber etwas ziemlich im argen. Irgendwo wird der Speicher überschrieben.
Da kann ich nur sagen "Viel Spass beim suchen":-D

Danke hat sich mittlerweile erledigt.
Habe meine eigene Funktion wieder eingebunden ohne den <vector> Kram.

gruss

[Fritzew]

Also Emil
mit Dir ist es manchmal schon lustig.....

Zitat:

Habe meine eigene Funktion wieder eingebunden ohne den <vector> Kram.

Wo kommt den das auf einmal her? In dem Thread nicht oder ich bin blind :lol:

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1379213)

Also Emil
mit Dir ist es manchmal schon lustig.....

Zitat:

Habe meine eigene Funktion wieder eingebunden ohne den <vector> Kram.

Wo kommt den das auf einmal her? In dem Thread nicht oder ich bin blind :lol:

Ich wollte nur darauf hinweisen das durch das einbinden und der Verwendung von <vector> das Problem erst auftrat.
Na man sollte auch mal Herzhaft lachen dürfen ;)

gruss

[jaenicke]

Das Problem bei überschriebenem Speicher ist, dass durch eine Änderung am Quelltext an einer ganz anderen Stelle das Überschreiben rein zufällig aussehende Effekte haben kann. Oder eben keine Effekte mehr.
Solange du also nicht die Ursache dafür gefunden hast, wirst du das Problem, dass plötzlich etwas ganz unlogisch passiert, immer wieder haben. Aber eben nicht voraussagbar und oft an ganz anderen Stellen als die Ursache und auch als die letzte Änderung.

Insofern macht es, wenn wirklich Speicher überschrieben wurde, wenig Sinn einfach zu hoffen, dass es kein Problem mehr gibt, wenn die Änderung nicht zielgerichtet das eigentliche Problem behoben hat...