11 svar · 377 visningar · startad av Nexus86
Skriver endast här för att
niko skrev:
Men annars vet jag inte. Har inte så bra koll på GDI-grejer. Du kan ju även prova C++-forumet eftersom frågan ändå är mer WinAPI-specifik än VB-specifik.
Hur gör man med API för att först kopiera en bild med BitBlt till en CompatibleDC och sedan spara bilden därifrån? (Kan skriva om till VB sen)
EDIT // Det är bara spara-biten jag behöver kod till :)
http://www.codeguru.com/mfc/comments/29116.shtml
Den innehåller i originalet ingen BitBlt, men funkar när jag byter:
RECT rect= {10,10,80,80};
FillRect(dc, &rect, (HBRUSH) (COLOR_WINDOW));
.. mot ..
HDC DeskHDC = CreateDC("DISPLAY", 0, 0, 0);
BitBlt (dc, 0, 0, 115, 115, DeskHDC, 0, 0, 0xCC0020);
.. i main(). Så det borde vara precis vad du letar efter.
Sen kommer det säkert att ta minst en halvtimme att porta den till VB.
ReleaseDC(DeskHdc) är inte att förglömma...
(En av de detaljerna när talesättet att "windows städar efter sig" inte alltid är riktigt överensstämmande ;) )
Here we go again .. :OO
Som du säkert vet så finns det vid det här laget åtskilliga versioner av "Windows". Det finns också många patch/service pack-nivåer inom varje version och dessutom många olika gdi-drivisar. Att då säga att "windows inte städar efter sig" är ungefär lika meningsfullt som att säga att "bilar har dåliga bromsar".
Det enda problem angående ReleaseDC och minnesläckor jag kunde hitta på nätet verkade hänföra sig till MFC vilket inte används i detta exempel. Mitt "eget" Windows (2000 Server sp3) verkar dessutom städa efter sig. Jag kan köra koden ovan ett 1000-tal ggr i en bat-fil utan att märka vare sig instabilitet eller resursläckor i form av minne eller handtag.
Men annars har du helt rätt. Det finns ingen anledning att inte anropa ReleaseDC. Hade det dessutom varit en applikaton som inte terminerade direkt så hade man varit tvungen att göra det för att bevara resurser under programmets körning.
Mitt Windows (2000 sp1) städar inte alltid efter sej men jag har ett program till det. Oftast så gör det det men inte alltid som sagt.
EDIT // niko: Man behöver inte ta CreateDC för att få DC till displayen. Går lika bra med GetDC(0). Iaf i VB vet inte i C++ då jag aldrig har behövt det.
Btw, vad är skillnaden på DeleteDC och ReleaseDC? Jag har alltid använt DeleteDC men om det är bättre med ReleaseDC går jag nog över.
Nexus86 skrev:
Man behöver inte ta CreateDC för att få DC till displayen. Går lika bra med GetDC(0).
Det gör det säkert. Som sagt, GDI är inte min grej, jag tog kod jag visste funkade för att testa.
Nexus86 skrev:
Iaf i VB vet inte i C++ då jag aldrig har behövt det.
CreateDC och GetDC har inget med VB eller C++ att göra. De är Windowsfunktioner.
Nexus86 skrev:
Btw, vad är skillnaden på DeleteDC och ReleaseDC? Jag har alltid använt DeleteDC men om det är bättre med ReleaseDC går jag nog över.
MSDN skrev:
The application must call the ReleaseDC function for each call to the GetWindowDC function and for each call to the GetDC function that retrieves a common DC.
An application cannot use the ReleaseDC function to release a DC that was created by calling the CreateDC function; instead, it must use the DeleteDC function. ReleaseDC must be called from the same thread that called GetDC.
Det borde alltså stått DeleteDC i PeWs inlägg ovan.
niko skrev:
Men annars har du helt rätt. Det finns ingen anledning att inte anropa ReleaseDC. Hade det dessutom varit en applikaton som inte terminerade direkt så hade man varit tvungen att göra det för att bevara resurser under programmets körning.
Precis. Det här tycker jag är en rätt viktig grej du säger. Man behöver inte släppa några DC's men se till att göra det ändå. Min uppfattning är att det inte är helt ovanligt att programmerare tänker: "Ah. Det där gör någon annan åt mig. Då behöver inte jag göra det."
Ibland kan det vara förrädiskt.
Hellre kolla så att ljusen är släckta en gång extra än att det börjar brinna... (Erhm.. Bra liknelse? :e )
Phorpher skrev:
Bra liknelse?
Ja, jag gillar själv liknelser:
Om jag går ut från en bioföreställning och slänger pop-cornkartongen på golvet så kan jag vara ganska säker på att personalen (Windows) så småningom kommer att städa efter mig för att undvika att biografkedjan (Microsoft) får dåligt rykte. Men det är ändå enklare, säkrare, snabbare, mer optimalt, och mer sympatiskt om varje person (process) städar efter sig själv.
niko skrev:
Here we go again ..
Som du säkert vet så finns det vid det här laget åtskilliga versioner av "Windows". Det finns också många patch/service pack-nivåer inom varje version och dessutom många olika gdi-drivisar. Att då säga att "windows inte städar efter sig" är ungefär lika meningsfullt som att säga att "bilar har dåliga bromsar".
Jag anar en viss snabbhet (och spydighet?) i dina svar då jag faktiskt inte alls skrev att windows aldrig städar efter sig, utan jag skrev att utrycket "windows städar alltid efter sig" är en smula felaktigt och inte alltid överensstämmande... en avsevärd skillnad eller hur?
Jag har inte heller rackat ned på operativen win* eller MS så vart ifrån resten av dina skrivelser kommer, vet bara du.
Det var av ren information till de som läser tråden jag belyste vikten av att städa - inget annat.
Det borde alltså stått DeleteDC i PeWs inlägg ovan.
Okej, visst. Kan så vara, det var ett antal rader kod sedan jag proggade i GDI :)
Det enda problem angående ReleaseDC och minnesläckor jag kunde hitta på nätet verkade hänföra sig till MFC vilket inte används i detta exempel. Mitt "eget" Windows (2000 Server sp3) verkar dessutom städa efter sig. Jag kan köra koden ovan ett 1000-tal ggr i en bat-fil utan att märka vare sig instabilitet eller resursläckor i form av minne eller handtag.
Nej, i just det där fallet kanske det går bra men om du itererar CreateDC >1000 ggr är det inte säkert att det går lika bra ;)
Hade själv under en större lab i skolan problem med en total grafikkrasch pga av slarv med städning (samma sak med samma kod i NT, w2k och XP (ej MFC, utan ren C-winAPI))... borde i det läget inte vara så himla fel att varna för konsekvenser som kan inträffa (?) .
PeW skrev:
då jag faktiskt inte alls skrev att windows aldrig städar efter sig, utan jag skrev att utrycket "windows städar alltid efter sig" är en smula felaktigt och inte alltid överensstämmande... en avsevärd skillnad eller hur?
Ja, du har rätt, din formulering är logiskt och semantiskt fullständigt korrekt och sann. Anledningen till att jag reagerade var dels att jag (miss)uppfattade att du ville gräva upp stridsyxan från den tidigare tråd där detta diskuterades, dels att jag (högst personligen) inte alls gillar att man använder termen "Windows" i såna här sammanhang. Jag tycker nämligen det riskerar att missuppfattas som att alla Windowsversioner är likadana och dras med exakt samma buggar/designproblem vs olika API:er, vilket de inte gör.
Folk tenderar att generalisera och säga saker som "Windows städar inte alltid efter sig", samtidigt som ingen säger att "Unix städar inte efter sig" bara för att det råkar finnas en resursläcka i ett systemanrop i nån specifik version av HP-UX. (OBS: Jag säger inte att du har sagt det. Det är bara en allmän reflexion.)
PeW skrev:
Hade själv under en större lab i skolan problem med en total grafikkrasch pga av slarv med städning
Innefattade den några globala systemhookar? Då brukar man kunna få sånt beteende.
PeW skrev:
borde i det läget inte vara så himla fel att varna för konsekvenser som kan inträffa (?) .
Återigen helt överrens. Jag tycker inte heller att det är fel att berätta att Windows (>=95) faktiskt är designat på så sätt att allt allokerat minne och alla GDI-objekt återgår till systemet då applikationen terminerar oavsett hur den terminerar eller om man själv explicit avallokerar. Avsteg från detta beror på buggar i specifika Windowsversioner eller på kod som ligger "under" Windows, tredjepartsdrivisar o dyl.
PeW skrev:
(spydighet?)
Äh, det säger du bara för att jag inte använder smilies ..
Gott :)
F.ö:
Innefattade den några globala systemhookar? Då brukar man kunna få sånt beteende.
Möjligt. Appen var multitrådad med globala handtag. Men det avhjälptes med att städa lokalt i funktionen, likt malloc & free.