Author Topic: Memory-mangement dilemma  (Read 3182 times)

zedd151

  • Member
  • *****
  • Posts: 1968
Re: Memory-mangement dilemma
« Reply #30 on: September 05, 2022, 06:07:02 AM »

 The buffer won't be overrun; the control simply won't let you add anything extra to it,


use EM_SETLIMITTEXT

Code: [Select]
invoke SendMessage, hCtl, EM_SETLIMITTEXT, 0, 1024000000   ;  <---- 1GB you won't need more I hope :P

Thats why I attached qikpad_largelimit.zip in a previos post as an example that it works
Regards, zedd.
:tongue:

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #31 on: September 05, 2022, 06:09:44 AM »
OK, so two definitive suggestions here, from JJ and Hutch. Regarding JJs, that's setting the text limit to the max. Hutch recommends some smaller values. Are there any bad consequences to setting the text limit to such high values? Will the edit control eat up all available memory?

Swordfish, I don't think you quite grasp the situation. You wrote "You only need to then retrieve text length AFTER text has been added.". But that would require a time machine; without increasing the text limit in the situation I described, you can't add any more text to the control. See how that works?

Again, ballparking seems to be the answer here. The question is about the size of the ballpark; Little League or Shea Stadium?

zedd151

  • Member
  • *****
  • Posts: 1968
Re: Memory-mangement dilemma
« Reply #32 on: September 05, 2022, 06:11:24 AM »
see post above, and see the attachment mentioned. run it with a large file, while watching Taskmgr Thats why I attached that file, so you can experiment with these issues there without crapping up your source code.


Just set the text limit very large. Most computers these days have tons of memory, I seriously doubt anyone will use all of it for a text file.
Regards, zedd.
:tongue:

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #33 on: September 05, 2022, 06:14:45 AM »
Look, Swordfish, I know you're trying to be helpful here, but I really need answers from someone who knows what the actual consequences of setting high limits on edit control text are, if any such people are hanging around here.

zedd151

  • Member
  • *****
  • Posts: 1968
Re: Memory-mangement dilemma
« Reply #34 on: September 05, 2022, 06:17:35 AM »
Setting the text limit has no ill effects by itself. qeditor has a very high text limit for example. sure its rich edit, but same rules apply. And after years of using and abusing by everyone, no issues in that regard.
Thats all I have to say.  :sad:
Regards, zedd.
:tongue:

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #35 on: September 05, 2022, 06:30:18 AM »
Ackshooly, it occurs to me:

Code: [Select]
     OR    IcouldTry,  aRichEditControl

(code would actually work if "aRichEditControl" were a constant ...)

jj2007

  • Member
  • *****
  • Posts: 13957
  • Assembly is fun ;-)
    • MasmBasic
Re: Memory-mangement dilemma
« Reply #36 on: September 05, 2022, 06:31:58 AM »
I really need answers from someone who knows what the actual consequences of setting high limits on edit control text are, if any such people are hanging around here.

Why don't you test it? That's what I have been doing, and I can assure you that setting the text limit to -1, i.e. 4,294,967,295 bytes does not crash my machine.

Btw speedwise it's a huge difference if ES_AUTOHSCROLL is set or not.

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #37 on: September 05, 2022, 06:33:48 AM »
Btw speedwise it's a huge difference if ES_AUTOHSCROLL is set or not.

Actually a necessity to not set it, otherwise you don't get line wrap; as Swordfish once wrote, the characters just fall off the right side of your monitor onto the floor.

The speed difference must come from having to invoke the line-wrapping code each time a line of text hits the right edge of the window.

jj2007

  • Member
  • *****
  • Posts: 13957
  • Assembly is fun ;-)
    • MasmBasic
Re: Memory-mangement dilemma
« Reply #38 on: September 05, 2022, 06:54:07 AM »
Btw speedwise it's a huge difference if ES_AUTOHSCROLL is set or not.

Actually a necessity to not set it, otherwise you don't get line wrap; as Swordfish once wrote, the characters just fall off the right side of your monitor onto the floor.

The speed difference must come from having to invoke the line-wrapping code each time a line of text hits the right edge of the window.

Well, they don't fall off, but if column 1024 is reached, the text gets merciless wrapped, right in the middle of a word. But it's definitely much faster with ES_AUTOHSCROLL (about a factor 10), see Qikpad.exe

However, most of the time we don't see this problem, simply because our sources don't have such line lengths. Use bible.zip to do real tests.

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #39 on: September 05, 2022, 07:23:16 AM »
I should have said "a necessity if you want line wrap", which I do want. Speed not so much an issue, though it would be nice.

jj2007

  • Member
  • *****
  • Posts: 13957
  • Assembly is fun ;-)
    • MasmBasic

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #41 on: September 05, 2022, 10:04:06 AM »
Interesting: the suggestion (apparently the only way to do this, to change between word-wrapping and not) is to destroy the control, then re-create a new one with different styles and transferring over the old buffer contents.

I was thinking of implementing this as a user option, but this method seems so ugly I think I'll just stick with one way or the other.

jj2007

  • Member
  • *****
  • Posts: 13957
  • Assembly is fun ;-)
    • MasmBasic
Re: Memory-mangement dilemma
« Reply #42 on: September 05, 2022, 05:46:30 PM »
Yep, that is the sad truth. In my editor, I just hit Ctrl W to toggle word wrap... but then, it's a richedit control.

The pooredit control was not designed for large texts and bells and whistles.

NoCforMe

  • Member
  • *****
  • Posts: 1124
Re: Memory-mangement dilemma
« Reply #43 on: September 05, 2022, 05:54:06 PM »
But I thought that RichEdit had the same limitation on not being able to change word wrap once the control was created, at least from everything I read online about it. Do you have some secret recipe that lets you change that without destroying and re-creating the control?

jj2007

  • Member
  • *****
  • Posts: 13957
  • Assembly is fun ;-)
    • MasmBasic
Re: Memory-mangement dilemma
« Reply #44 on: September 05, 2022, 06:02:10 PM »
secret recipe

invoke SendMessage, hEdit, EM_SETTARGETDEVICE, 0, 1      ; 0=wrap, 1=no wrap