Announcement

Collapse
No announcement yet.

Invalid Memory Location

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

  • Michael Mattias
    replied
    ????
    EM_SETTEXTEX
    The EM_SETTEXTEX message combines the functionality of WM_SETTEXT and EM_REPLACESEL and adds the ability to set text using a code page and to use either Rich Text Format (RTF) rich text or plain text.

    Leave a comment:


  • Edwin Knoppert
    replied
    FYI, there are alternatives in RTF streaming.
    I have a 'count' callback which provides me the required buffer.
    It is a similar callback but without MoveMemory() and such.

    The 2nd time i actualy copy the data over to the pre-determined size string.
    You may also consider this for speed reasons.
    Just try.

    Is the RTF ok?
    The {} characters need to be aligned!

    Leave a comment:


  • Michael Mattias
    replied
    Guilty of not even looking at it, but...

    Sure sounds like you may have made a naughty on one of your TRACE PRINT statements. I think I'd chech those before I did anything else. (The presupposition is, the compiler does NOT have a bug, which is a very very very good supposition).

    Also, bear in mind that if you removed the trace by using #TOOLS OFF (best way I can think of), you are no longer running the same executable as when compiled with #TOOLS ON... meaning, of course, that whatever memory corruption is being introdoced by the applications code may not exhibit a problem at the same place... or not exhibit it all.

    MCM
    Last edited by Michael Mattias; 30 Aug 2008, 12:56 PM.

    Leave a comment:


  • Cliff Nichols
    replied
    Back to the drawing board

    Well back to the drawing board. I found Borje's code to show an RTF with images, but as soon as I added Trace to verify no crashes, thats when it crashes.

    Is it something I am doing? or something I should send to PB about a possible bug? If someone can see what I can't please let me know
    Attached Files

    Leave a comment:


  • Cliff Nichols
    replied
    Chris...believe it or not...your post over in Making About Boxes" Has led me to another option of doing the same concept I am doing (just slightly different), so MEGA THANXXXX

    I am still curious as to the oddities of the problem, but I think Borje has the answer with working code (Yet Again )

    The good part is the learning I have done so far....(experiment with macros and try to build a better debugger in things that just bugger the "Bleeeeep" outta me"

    On to see if I can make Borje's code make sense to me (it works without crashing) and compare it to my trials of my attempt. (maybe even include my Errorchecking routines) *LOL*

    Leave a comment:


  • Chris Holbrook
    replied
    Originally posted by Cliff Nichols View Post
    so there should be one more callback that never occurs and my Bytes Remaining: 708 still??? (Thinking some mis-alignment of data or something???)
    The only thing I can think of that could stop this kind of copy in this way would be running out of buffer. I looked at the code but it's been a long day... What size buffer are you allocating?

    Leave a comment:


  • Cliff Nichols
    replied
    You would't want to do it every day, but be honest: every now and then it's kind of fun to deploy the debugging tools (eg TRACE) and find an elusive bug, isn't it?
    True, but only fun at first (or last when you finally find the answer)

    Unfortunately in my case its been 3 days of working on this and still I can not find it.

    I even went overboard and built my own ErrorHandling.INC to help me track it down.....(shortly will post the INC in the source code forum, but I am including it in this zip so others can see the 2 reports I get)

    I also went nuts, and created a variable that everytime I call a API function (like SendMessage for example) that I set the variable equal the string of that function (just because I still can't find the cause, but maybe there is a better way of tracking this??????)

    In the attached zip, if you use the Text only version of the RTF you will see in the "RICHCOM_TEXT" function I get
    LastFunction = MoveMemory BYVAL pbBuff, BYVAL dwCookie.pszText + dwCookie.Currpos , pcb
    Last WindowsError # 6 - The handle is invalid.

    Last PbError # 0 - No Error at line: 1
    If you use the Test.RTF, which is the same file (but with the picture included) you will not see this error, but you will also see that after the last call to RICHCOM_EDITSTREAMINCALLBACK causes the crash, and the log ends
    RICHCOM_EDITSTREAMINCALLBACK(tÈ(<00>¨q<04><00>è^<04><00>,2967692,4092,1238880)
    RICHCOM_EDITSTREAMINCALLBACK Exit
    And if a real glutton for punishment, if you uncomment the block in the "RICHCOM_EDITSTREAMINCALLBACK" and look at the full data, that the crash occurs "Supposedly at the end" because all the data matches the RTF seen in notepad, but my results show
    ******************************************************************************************
    Bytes in Chunk: 4092 Bytes Written: 290532 Bytes Remaining: 708 Bytes Total: 291240
    Times Called: 71 Times should be called: 72
    ******************************************************************************************
    so there should be one more callback that never occurs and my Bytes Remaining: 708 still??? (Thinking some mis-alignment of data or something???)

    So I ask
    1. What is the Invalid Handle I find with the text only version??? (I can't find it)
    2. Why does this error not show when using the same RTF file but including a picture????
    3. Why does non of the errors occur if no tracing whatsoever? (See my earlier post, where I had functions that would do a trace, but I never used the function, so it should not have effected results)
    4. Why am I still spinning my wheels after 3 days and nights of trying to track this down for something as a simple a subject (or so I thought) to show a picture in a RTF file?

    Can ANYONE see what I can not see?????
    Attached Files
    Last edited by Cliff Nichols; 29 Aug 2008, 04:59 PM. Reason: Forgot Attachment

    Leave a comment:


  • Michael Mattias
    replied
    You would't want to do it every day, but be honest: every now and then it's kind of fun to deploy the debugging tools (eg TRACE) and find an elusive bug, isn't it?

    I'm very pleased when I have that "Eureka!" moment, although sometimes it's more like a :doh: moment.

    What scares me is when I "fix" a problem but have no clue why that fix "works."

    Leave a comment:


  • Cliff Nichols
    replied
    Test Results and where the problem lies

    After further testing, I took things a notch higher where my gut instinct was telling me I am reading beyond the end of the file may be partially right, but here is the sample with the debugging tools I tested with.

    also please note to ignore my comments in the code about why Trace was not working properly....Lawrence already answered me before I posted the question

    Because of the size of the resulting Trace files, I have included a test results of all text vs text with picture. Hopefully someone can spot what I can not spot (although I think its in the dll itself because with a picture, although the full file is read, the callback does not fire to gather the last 708 bytes?????)
    Attached Files

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    FUNCTION PBMAIN() AS LONG 
      TRACE NEW "tracefile"
      TRACE ON 
      CALL RealPbMain() 
      TRACE OFF
      TRACE CLOSE
    END FUNCTION

    Leave a comment:


  • Laurence Jackson
    replied
    Cliff, I haven't got anything really sensible to contribute, it's as much a mystery to me as it is to you, but just to say that I don't think you can do what you are doing with TRACE because
    An implied TRACE OFF is performed when you exit the procedure in which the current TRACE ON was executed.
    From the PB help file.

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    <Note, Kev posted while I was composing.>

    I must be missing something here. The NOT Working version will run if the call to:
    Code:
        RichCom_LoadFromFile GetDlgItem( hDlg, 100 ), "Test.rtf"
    is commented out, so it appears to me the problem is in RichCom.Inc, not in the PB code.

    What am I missing?

    ==================================
    I do not feel obliged to believe
    the same God who has endowed us
    with sense, reason, and intellect
    intended us to forgo their use.
    ~ Galileo Galilei
    ==================================
    Last edited by Gösta H. Lovgren-2; 27 Aug 2008, 08:14 PM.

    Leave a comment:


  • Kev Peel
    replied
    Cliff,

    Thanks for posting the code.

    I ran some tests on the first program, and the error seems to be in processing the RTF text data. There is no error with the read or write buffer or the code used to load the buffer, the GPF is caused by the RichEdit DLL itself. Also, I tried it with RichEdit20.dll (version 2) and it also GPFs.

    Leave a comment:


  • Cliff Nichols
    replied
    Interesting Test

    Ok after alllllll day trying to track down a bug, I think I FINALLY have an interesting one, that in my mind verges on if I need to submit to PB for a possible bug???

    Anyways...the 2 below are identical, but one works...one does not and if I eliminate the picture in the RTF then they both work, but that may be the cause of multiple things that I am not aware of at the moment.

    Here is my testing (both involving "TRACE")
    1. Create functions for Trace (But do not call them)
    2. Do NOT Create functions for Trace, and do not call them


    As you will see, in one I did a trace, in another I commented it out....and if I comment out then all works fine???????, but if I allow a trace then the closest thing I can find so far is possibly streamin reading beyond the end of file??? (testing on those levels show me it reads up to end of the file minus the last chunk, so thats another story for later)

    Right now I am curious why 2 identical codes, 1 with debugging crashes, one without does not???? and in both I suspect something to do with reading and writing, but I have not gone as far as opening a file and logging on my own yet...but that should be the next step)

    Can anyone spot what is wrong so far?????
    Attached Files

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Originally posted by Cliff Nichols View Post
    Gosta, my bad.....I went back to my post and added the RTF file....maybe that will make the difference in replicating the problem?
    Cliff, As far as I can see the problem is in your rtf file. It opens another rtf just fine but gpfs when trying to open your rtf.

    I opened test.rtf in Word and deleted the graphic, and now your example runs fine, so the problem appears you can't load a graphic.

    ''<<<Added later>>> It doesn't seem to make any difference if Trace is ON or OFF. GPF's with the graphic.


    =========================================
    "The only way to get rid of a temptation
    is to yield to it."
    Oscar Wilde (1854-1900)
    =========================================
    Last edited by Gösta H. Lovgren-2; 27 Aug 2008, 12:58 PM. Reason: Added moxie

    Leave a comment:


  • Michael Mattias
    replied
    gracias, beaucoup better.

    Leave a comment:


  • Cliff Nichols
    replied
    Right you are MCM....I went back and changed it to a zip file. Thanks for the hint,

    Leave a comment:


  • Michael Mattias
    replied
    At the size of that RTF, I think an "attachment" would have been a better choice than inline posting. Takes approximately forever to load and view this page.

    Fortunately, "edit" of posts is allowed, he subtly hinted.

    Leave a comment:


  • Cliff Nichols
    replied
    Gosta, my bad.....I went back to my post and added the RTF file....maybe that will make the difference in replicating the problem?

    So far I have been led from the debugger in animate that when I am alerted to an invalid memory location, is in the streamin function (still tracking what though)

    Leave a comment:


  • Gösta H. Lovgren-2
    replied
    Cliff,

    Your example works fine here (8.04 XP Pro Sp3). No errors or gpf's. Of course I'm not using the same Test.rtf (you didn't provide it.).

    No dif if Trace On/Off.

    ==============================
    "Everybody pities the weak;
    jealousy you have to earn."
    Arnold Schwarzenegger (1947-)
    ==============================
    Last edited by Gösta H. Lovgren-2; 27 Aug 2008, 09:15 AM. Reason: Clarity, not confusion.

    Leave a comment:

Working...
X