Announcement

Collapse
No announcement yet.

Folder Name As

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Whenever you make calls to GDI+, you should do so by calling the methods and functions provided by the C++ wrappers. Microsoft Product Support Services will not provide support for code that calls the flat API directly
    You need to consider that some of the support people may have never seen "flat API" programming.. they were all born and raised with object-oriented programming.

    "Support availability" is probably the main reason I have upgraded the software I have used over the years... too many times "support" was limited to the current version or maybe one back... not officially, of course, but practically, for sure.


    Consider your issue here... how many support techs would know what you had to discover about GDI+ ???
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #22
      Somewhere in this discussion I might have expected Jose to jump in and explain how I abused his code (I think he's the source for the GDIP code I am using). Or for that matter, how I might still be abusing his code?

      Comment


      • #23
        Howdy, MCM

        ... people may have never seen "flat API" programming
        Yep, I've wondered at times if the PowerBASIC forum is one of the last bastions of flat API use. Surely there are other holdout groups but I've not gone looking for them.

        added ... https://bookauthority.org/books/best-win32-api-books ... the latest book on the list was written in 2000.

        Comment


        • #24
          Originally posted by Gary Beene View Post
          I put these next two lines of GDIP cleanup code in Image Gallery under WM_Destroy, to run when the app closed.
          Code:
          GdipDisposeImage(pImage) 'GDIP cleanup
          GdipDeleteGraphics(pGraphics) 'GDIP cleanup
          But in a quick test, I think adding those two lines to the GalleryLoadSoloFromFile function is necessary. Give me a couple more minutes to confirm that is the fix.

          If so, I mistakenly thought the two lines of code were end-of-app cleanup rather than being necessary after loading each file.
          I found this on the intertubes which explains why you need those lines before trying to rename the folder (or rename/delete the file!)

          " GDI+, ..., may defer the decoding of raw image bits until the bits are required by the image. Additionally, even after the image has been decoded, GDI+ may determine that it is more efficient to discard the memory for a large Bitmap and to re-decode later. Therefore, GDI+ must have access to the source bits for the image for the life of the Bitmap or the Image object.

          To retain access to the source bits, GDI+ locks any source file, and forces the application to maintain the life of any source stream, for the life of the Bitmap or the Image object."


          It's in an old KnowledgeBase article:

          https://www.betaarchive.com/wiki/ind...Archive/814675

          Comment


          • #25
            Howdy, Stuart!

            Thanks for that information. I'll have to keep it in mind as I work with other GDIP API.

            It is interesting that code that has stood the test of decades of use can reach out and bite someone when used for different slightly differently.

            Comment


            • #26
              The solution is to copy the GDI+ image into a 32-bit DIB, then you can use GdipDisposeImage(img), and work directly with the DIB.
              Patrice Terrier
              www.zapsolution.com
              www.objreader.com
              Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

              Comment


              • #27
                Howdy, Patrice!

                Thanks for the response. However, I already copy the image into a memory bitmap and work directly with that. At some point I have to work with the file and in my posted code I did not use GdipDisposeImage immediately after creating the bitmap, so GDIP kept a lock on the file, preventing me from deleting the folder that contained it. Timely use of GdipDisposeImage solved that problem.

                I don't see how using a DIB vs a DDT memory bitmap would have fixed the lack of using GdipDisposeImage. Can you clarify what you meant?

                Comment


                • #28
                  Using a DIB you can work in full 32-bit mode, using the alpha channel to perform alphablending. And once converted to DIB you don't need to use anymore the graphic img.
                  If ever you need it again, you can convert the bitmap back to image using the GdipCreateBitmapFromScan0 flat API.

                  However i don't think that DDT graphic is able to work with alpha channel (24-bit only).
                  Patrice Terrier
                  www.zapsolution.com
                  www.objreader.com
                  Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

                  Comment


                  • #29
                    > I don't know if that hurts my feelings or not? If we use flat API we are second-class customers? Pooh on that!

                    First they wrote the flat API and then wrote C++ wrapper classes to use them, but they choose to document only the classes and not the flat API. I wrote a help file documenting the flat API that apparently has been used more by users of other languages (MASM, PureBasic, Ansi C...) than by PBers.

                    The main problem of using the flat API is that there are no examples for it in MSDN.
                    Forum: http://www.jose.it-berater.org/smfforum/index.php

                    Comment


                    • #30
                      If ever you need it
                      I did post, on my private forum, a Flat API header for 64-bit (based on my PB's GDIPLUS Helper from 2002)
                      http://www.objreader.com/index.php?topic=72.0

                      This version uses GetprocAddress to bypass the nasty class encapsulation.

                      I do have somewhere a complete PB example, that is a direct translation of the original MSDN GDI+ Flat API example
                      that was provided with my GDIPLUS Helper 19 years ago. Let's see if i can retrieve it.
                      Patrice Terrier
                      www.zapsolution.com
                      www.objreader.com
                      Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

                      Comment


                      • #31
                        Ok, i found a zip file from 2005 with the related GDIPLUS examples that i wrote for PB.
                        The problem is that i have exhausted my attachment quota here, thus i shall make tomorrow a copy of it on my private forum (www.objreader.com).
                        Patrice Terrier
                        www.zapsolution.com
                        www.objreader.com
                        Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

                        Comment


                        • #32
                          There are hundreds of examples in my subforum, both using the flat API and wrapper classes.
                          But nothing of this is relevant to the original post. The key is that, for performance reasons, GDI+ locks the file that it is using. Therefore, while it is using it, you can't delete it, rename it or rewrite it. Stuart has already exaplained that in post #24.
                          It we are going to discuss programming with GDI+, this is not the appropriate thread.
                          Forum: http://www.jose.it-berater.org/smfforum/index.php

                          Comment

                          Working...
                          X