Announcement

Collapse
No announcement yet.

RT Error 5

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

  • Michael Mattias
    replied
    I did not look real carefully so this may not be your specific difficulty, but the handle returned by the PB "BITMAP LOAD" or other 'DDT' image functions is proprietary and therefore not usable by WinAPI functions. (And vice-versa). (See #17 by Walt Decker.. this is an expansion of same).



    MCM

    Leave a comment:


  • Walt Decker
    replied
    Perhaps it is a PB compiler thing. I know that the handle returned by LOAD BITMAP cannot be used with getdc() API.

    Leave a comment:


  • Rodney Hicks
    replied
    Well, Walt, the thing I learned from this is that the most recently created bitmap doesn't seem to attach the whole 'stream'. At least not every time. Don't know why the handle would be good but the DC not.

    I'm happy, but I was more happy when ignorant of that!

    Leave a comment:


  • Walt Decker
    replied
    Thank you, Mr. Hicks.

    It is no big deal. I have changed the function to use loadimage and it appears to work fine.

    I would post the code, but it is fairly long.

    I am updating the mdi-clone code I posted in the source code forum several years ago. Just thought I would use the PB run-times instead of the API.

    Leave a comment:


  • Rodney Hicks
    replied
    I use the label system with #DEBUG DISPLAY lots and it works pretty good. I don't recall an instance of it not working. I have gone so far as to put a label every second line, which I would do in that small function. However, in the absence of compilable code, I put your load function into an existing program an made the following changes. Added the bitmap handle as a parameter, commented out the declare in the load function. I just copied the loaded bitmaps to my graphic control since I didn't have your setup.
    '
    Code:
    FUNCTION FN_PbLoadBitMap(BYVAL BmpName AS STRING, BmpDc AS DWORD, bmphndl AS DWORD) AS DWORD
    
    'LOCAL BmpHndl AS DWORD
    
    IF ISFILE(BmpName) = 0 THEN EXIT FUNCTION
    
    GRAPHIC BITMAP LOAD BmpName, 0, 0 TO BmpHndl
    
    IF BmpHndl = 0 THEN
    MSGBOX "LOAD FAILED"
    EXIT FUNCTION
    END IF
    
    GRAPHIC ATTACH BmpHndl, 0 '<----- ERROR 5 here
    GRAPHIC GET DC TO BmpDC
    
    FN_PbLoadBitMap = BmpHndl
    END FUNCTION
    '
    However, when I commented out the GRAPHIC ATTACH in the load function the images were copied but only the first image's bmpDC came through. the following bmpDCs were all zero, so the GRAPHIC ATTACH is necessary for the graphic DC. It never failed to copy the images or produced an error. The bmphndl came through without the GRAPHIC ATTACH.

    Leave a comment:


  • Walt Decker
    replied
    There is no GRAPHIC WINDOW or GRAPHIC CONTROL. I bitblt the bitmap to the surface of an MDI-clone. As soon as that is accomplished I :

    Code:
    FUNCTION FN_PbDestroyBitMap(BmpHndl AS DWORD, BmpDc AS DWORD) AS LONG
    
    IF BmpHndl < 1 THEN
        BmpHndl = 0
        BmpDC = 0
        FUNCTION = 1
        EXIT FUNCITON
    END IF
    
    GRAPHIC ATTACH BmpHnd, 0
    GRAPHIC BITMAP END
    
    BmpHndl = 0
    BmpDc = 0
    FUNCTION = 1
    END FUNCTION
    The thing that is failing is the GRAPHIC ATTACH; but not consistently.
    GRAPHIC LOAD is returning a handle. Whether the handle is valid I haven't a clue because I can not trap the error 5 unless I but in a debug break just before it and then physically step through the attach.

    I think I will just re-write the function to use loadimage and be done with it.

    Leave a comment:


  • Rodney Hicks
    replied
    In that function it is always the most recently developed bitmap, you might need it outside the function if you're going to make changes to the bitmap but for copying or stretching the target graphic window or control has to be attached.

    Leave a comment:


  • Walt Decker
    replied
    I need that line because it may not be the most recently created bitmap.

    The full app is capable of displaying a number of MDI clones, each of which has it's own bitmap. In WM_PAINT I load the appropriate bitmap, display it, then destroy the loaded bitmap.

    Leave a comment:


  • Rodney Hicks
    replied
    Perhaps you don't need that line as the most recently created bitmap is automatically attached.

    Leave a comment:


  • Walt Decker
    replied
    Mr. Hicks, I tried both your suggestions. Removing the "$" from the LOAD had no effect. Adding line numbers pointed to where the problem is, but does not let me resolve it. I need some kind of error trap to resolve the problem of change from the DDT "LOAD BITMAP" to the API "LOADIMAGE." The latter may be a better solution anyway.

    Leave a comment:


  • Rodney Hicks
    replied
    You can trap it by using #DEBUG DISPLAY ON and putting a couple of labels in the code.

    Leave a comment:


  • Rodney Hicks
    replied
    GRAPHIC BITMAP LOAD BmpName$, 0, 0 TO BmpHndl,
    The above line should have the dimensions of the bitmap, not 0,0, methinks.
    Okay, on further reading maybe not.
    Try removing the $ from the name since it's declared without it in the call to the function.

    Leave a comment:


  • Walt Decker
    started a topic RT Error 5

    RT Error 5

    I have a routine that looks like this:
    [code]
    FUNCTION FN_PbLoadBitMap(BYVAL BmpName AS STRING, BmpDc as DWORD) AS DWORD

    LOCAL BmpHndl AS DWORD

    IF ISFILE(BmpName$) = 0 THEN EXIT FUNCTION

    GRAPHIC BITMAP LOAD BmpName$, 0, 0 TO BmpHndl

    IF BmpHndl = 0 THEN
    MSGBOX "LOAD FAILED"
    EXIT FUNCTION
    END IF

    GRAPHIC ATTACH BmpHndl, 0 '<----- ERROR 5 here
    GRAPHIC GET DC TO BmpDC

    FN_PbLoadBitMap = BmpHndl
    END FUNCTION
    [code]

    Most of the time this works. However, sometimes, although the file to load is valid and produces a handle, the attach fails.

    Is there a way to trap error 5 other than "TRY" or "ON ERROR". Both of those do not work.

Working...
X