1. API curiosity
I found this so strange... thought I'd mention it.
In writing a little proggy using only API, I declared two atoms for the window's
titles as follows:
atom normal, working
normal=allocate_string("Normal Title")
working=allocate_string("Working Title")
The pointer to 'normal' was obviously used in CreateWindowEx(), to set the
window's title.
... and in my 'event handler', I had the following simple code:
void=c_func(xSetWindowText,{hwnd,working})
do_some_stuff()
void=c_func(xSetWindowText,{hwnd,normal})
I was quite surprised that this wouldn't work, because once the title had been
changed by the first xSetWindowText(),
the memory pointed to by 'normal' no longer contained the 'literal' string
"Normal Title".
So much for re-useability...
... just guessing by the gibberish contained in the title bar, it may even be a
pointer ?
If this is the case, how many other seemingly simple API functions do weird
things like this ?
2. Re: API curiosity
Welcome to the world of Euphoria's garbage collection 
. Whenever you
use allocate, you should lock the memory location so it doesn't get
swapped out. I honestly can't think of a case where you wouldn't lock
the memory after allocating, but maybe someone else can.
Michael J. Sabal
>>> wolfritz at KING.IGS.NET 02/14/02 12:48PM >>>
I was quite surprised that this wouldn't work, because once the title
had been changed by the first xSetWindowText(),
the memory pointed to by 'normal' no longer contained the 'literal'
string "Normal Title".
So much for re-useability...
... just guessing by the gibberish contained in the title bar, it may
even be a pointer ?
If this is the case, how many other seemingly simple API functions do
weird things like this ?
3. Re: API curiosity
- Posted by euman at bellsouth.net
Feb 14, 2002
Any chance you might send this to me for curiosity purposes.
Euman
euman at bellsouth.net
4. Re: API curiosity
Michael J. Sabal writes:
> Welcome to the world of Euphoria's garbage collection . Whenever you
> use allocate, you should lock the memory location so it doesn't get
> swapped out. I honestly can't think of a case where you wouldn't lock
> the memory after allocating, but maybe someone else can.
99.9% of users should *never* call lock_memory().
It doesn't even work on WIN32 or Linux, only on DOS.
Don't worry, other people have the same misconception.
lock_memory() should *only* be used on DOS, and only
for a hardware interrupt handler written in Euphoria.
lock_memory() is needed in that one, highly-specialized,
situation because when a hardware interrupt occurs you
don't have the time, or the ability, to make the operating system
retrieve a piece of swapped out code or data. In any other situation,
it's perfectly ok for memory to be swapped out. That's the
operating system's job. Don't worry about it.
Euphoria does not garbage collect memory that you allocate().
That's your job, using free().
I don't know why Wolf's code is not working.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: API curiosity
On Thu, 14 Feb 2002 16:53:40 -0500, you wrote:
>99.9% of users should *never* call lock_memory().
>It doesn't even work on WIN32 or Linux, only on DOS.
>Don't worry, other people have the same misconception.
>lock_memory() should *only* be used on DOS, and only
>for a hardware interrupt handler written in Euphoria.
>lock_memory() is needed in that one, highly-specialized,
>situation because when a hardware interrupt occurs you
>don't have the time, or the ability, to make the operating system
>retrieve a piece of swapped out code or data. In any other situation,
>it's perfectly ok for memory to be swapped out. That's the
>operating system's job. Don't worry about it.
Maybe you should note this in library.doc
Pete
