Recent posts

#11

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 25, 2024, 09:32:19 AM

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 ...

#12

The Workshop / Re: A useful tool: BMP data vi...

Last post by jj2007 - November 25, 2024, 09:19:04 AM

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.

#13

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 25, 2024, 09:16:11 AM

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?

#14

The Workshop / Re: A useful tool: BMP data vi...

Last post by jj2007 - November 25, 2024, 09:13:12 AM

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.

#15

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 25, 2024, 09:08:38 AM

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.

#16

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 25, 2024, 09:00:11 AM

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.

#17

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 25, 2024, 08:56:34 AM

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.

[Orrr]

#18

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 25, 2024, 08:40:36 AM

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.

#19

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 25, 2024, 07:39:12 AM

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.

#20

RadAsm IDE Support / Re: RadSTM32 update

Last post by Biterider - November 25, 2024, 05:57:17 AM

Hi KetilO
Works nicely. Thank you! 

Biterider