A useful tool: BMP data viewer

[NoCforMe]

Anyway, I have updated my little test proggie in reply #31, if anyone is interested.

I tried it. It faults (on PUSH ESI). ???

[zedd151]

Anyway, I have updated my little test proggie in reply #31, if anyone is interested.

I tried it. It faults (on PUSH ESI). ???

Exactly where? I see no issues, even running in debugger, stepping in every instance where esi is pushed to the stack. No such errors here.    Maybe I'll have to fire up windows 7 to see if any difference, than when run on win 10.

Anyway, I added a check for whether the bitmap (2.bmp) is present. If not present, the program simply exits.

[TimoVJL]

Worked with Windows 7 x64

[NoCforMe]

OK, I just learned something important.

That loooong delay where my program goes into a catatonic state? That's not my code.
My code is pretty fast.
The delay is the time it takes to dump the text in my buffer to the edit control!

Yikes.

I proved this by displaying "done" in the edit control when my pixel-displaying code is finished. The long wait happens after that. While that operation is going on, Windows goes into a coma.

So now, questions (to self):
I could display the text myself in a window using GDI text functions, which would surely be faster than waiting on the edit control to churn through all that text.
However, that would defeat the purpose of having the edit control in the first place, which is to make the text selectable in case the user wants to copy any of it.

Maybe copying the text from my buffer into the edit control in smaller chunks would be faster? I'll try that.

So what do y'all think I should do? Is it important that the text be selectable? Another option would be to write the text to a file, which I'm sure would also be faster than waiting on the edit control to fill up.
Copying the buffer to the edit control in small chunks only makes it more painful, so scratch that.
I tried hiding the window, hoping that would speed things up by not actually displaying anything:

Code Select Expand

          INVOKE ShowWindow, ResultsDispHandle, SW_HIDE
but for some reason that didn't work at all.

[zedd151]

Another option would be to write the text to a file, which I'm sure would also be faster than waiting on the edit control to fill up.

I just tested a 15 MB file, opening with both notepad and qeditor. Both of them open the file very quickly. i.e., dont blink or you will miss it.  How about first writing the data to a file, then load it into your edit window using a rich edit contol and 'stream' the data in.

From masm32 example 'riched'

Code Select Expand

ofCallBack proc dwCookie:DWORD,pbBuff:DWORD,cb:DWORD,pcb:DWORD
    invoke ReadFile,dwCookie,pbBuff,cb,pcb,NULL
    mov eax, 0
    ret
ofCallBack endp


StreamFileIn proc hEdit:DWORD,lpszFileName:DWORD

    LOCAL hFile :DWORD
    LOCAL fSiz  :DWORD
    LOCAL ofs  :OFSTRUCT
    LOCAL est  :EDITSTREAM
    LOCAL buffer[32]:BYTE
    LOCAL aval[8]:BYTE

    invoke OpenFile,lpszFileName,ADDR ofs,OF_READ
    mov hFile, eax

    mov est.dwCookie, eax
    mov est.dwError, 0
    mov eax, offset ofCallBack
    mov est.pfnCallback, eax

    invoke SendMessage,hEdit,EM_STREAMIN,SF_TEXT,ADDR est

    invoke GetFileSize,hFile,NULL
    mov fSiz, eax

    invoke CloseHandle,hFile

    szText OpenMsg,"Opened at "
    szText OpenByt," bytes"

    mov buffer[0], 0

    invoke szCatStr,ADDR buffer,ADDR OpenMsg

    invoke dwtoa,fSiz,ADDR aval
    invoke szCatStr,ADDR buffer,ADDR aval
    invoke szCatStr,ADDR buffer,ADDR OpenByt

    invoke SendMessage,hStatus,SB_SETTEXT,3,ADDR buffer

    invoke SendMessage,hEdit,EM_SETMODIFY,0,0

    mov eax, 0
    ret

StreamFileIn endp

Orrr... just use a rich edit control and try the other way... rather than a text box.

[NoCforMe]

How about first writing the data to a file, then load it into your edit window using a rich edit contol and 'stream' the data in.

The first part of that makes absolutely no sense: writing to a file has got to be a lot slower than storing the text in a buffer, which is what I'm already doing.

However, the second part of your suggestion might work: basically substituting a RichEdit control for the lowly edit control. Will try that.

[zedd151]

The first part of that makes absolutely no sense: writing to a file has got to be a lot slower than storing the text in a buffer, which is what I'm already doing.

My tests have shown that it can be very fast indeed to write to a file. But...

However, the second part of your suggestion might work: basically substituting a RichEdit control for the lowly edit control. Will try that.

Should be noticeably faster. Perhaps even much faster... than the simple edit control.

[NoCforMe]

The first part of that makes absolutely no sense: writing to a file has got to be a lot slower than storing the text in a buffer, which is what I'm already doing.

My tests have shown that it can be very fast indeed to write to a file. But...

Yes, but it can't possibly be as fast as writing to a memory buffer, since it involves transfer to a physical device.

[jj2007]

writing to a file has got to be a lot slower than storing the text in a buffer

There is not much of a difference because you don't really write to a file; you just hand over the content to the OS, which transfers it physically to a drive whenever it finds the time to do so.

[NoCforMe]

writing to a file has got to be a lot slower than storing the text in a buffer

There is not much of a difference because you don't really write to a file; you just hand over the content to the OS, which transfers it physically to a drive whenever it finds the time to do so.

OK. Makes sense since the call to WriteFile() returns before the data is actually written to disk.

So what can you tell us about the relative speeds of writing text to a RichEdit control vs. an ordinary edit control, because you're probably the resident expert on things RichEdit?

[jj2007]

relative speeds of writing text to a RichEdit control vs. an ordinary edit control

No idea, I've never tested that. All I can tell you is that streaming in plain text is fast but rtf can be slow if it's in the megabyte range.

[NoCforMe]

Question: is it really faster, with a RichEdit control, to use EM_STREAMIN vs. just setting the text all at once from a buffer, using SetWindowText()? I don't see the advantage of sending the text in pieces if it's all in one buffer to start with, which is the case here.

And this is plain text, not RTF.

I suppose I should just shut up and try it ...

[zedd151]

Question: is it really faster, with a RichEdit control, to use EM_STREAMIN vs. just setting the text all at once from a buffer, using SetWindowText()? I don't see the advantage of sending the text in pieces if it's all

No, you dont use EM_STREAMIN to set the text in rich edit control (I have never seen it used that way, or know if that is even possible), WM_SETTEXT works fine. That suggestion was for if you were to write to file first.

[NoCforMe]

Well, that's all moot now because guess what?
RichEdit is waaaaaay faster!
(I'm using SetWindowText(), same difference as WM_SETTEXT.)
Check out attached .exe (I'm cleaning up code and will post that later).
So much faster! So JJ, now we know. (No timings, but I could do that if anyone's interested.)

Now it's a real usable tool.

[zedd151]

RichEdit is waaaaaay faster!.

We all knew that your code itself was not the issue. Glad you have it all sorted.