1. Probably for David Cuny
Problem,
I was going to use this code as a handy way of viewing what is happening in
a Windows prog.
--my_string value obtained by program
--my_string = {32,50,54,48,48,32,49,53,50,50,32,53,52,51,57,56,55,50}
string_address = allocate_string(my_string)
ok = c_func(SetWindowText, {window_handle[5],
string_address})
this works perfectly except that the window title
should be (from my_string)
2600 1522 5439872
but actually shows (from SetWindowText)
2600 1511 5428861
Any suggestions
Many thanx
Terry
2. Re: Probably for David Cuny
Terry Moriarty wrote:
<snip>
Tracing is probably helpful.
-- David Cuny
3. Re: Probably for David Cuny
David
I had already used Trace to verify the value of my_string
before posting, so to reiterate
with trace window open
my_string(on trace window)
= {32,50,54,48,48,32,49,53,50,50,32,53,52,51,57,56,55,50}
which translates to " 2600 1522 5439872"
but the window title displays 2600 1511 5428861
What I can't figure is the -1 discrepancy between
my_string[offsets] 9, 10, 14, 15, 17 and 18.
Thanx for the interest
Terry
4. Re: Probably for David Cuny
Terry Moriarty wrote:
> I had already used Trace to verify the value
> of my_string before posting, so to reiterate...
There's just not enough information here. Are you saying that you give it
one value, and it shows another? Or does it show an old value, and not
update it when you send a new value? Where does the string value come from?
How are you sending the message? Is it failing, or what? Can you distill it
down to a small example?
-- David Cuny
5. Re: Probably for David Cuny
If your using setwindowtext on main window then you will be setting the
text in your TITLE bar. Are you sure that is what you want.
also you may want to use sprintf
Bernie
6. Re: Probably for David Cuny
- Posted by Terry Moriarty <terry at EDERNEY.IDPS.CO.UK>
Jul 26, 1999
-
Last edited Jul 27, 1999
David
>There's just not enough information here. Are you saying that you give it
>one value, and it shows another?
Exactly.
>Or does it show an old value, and not
>update it when you send a new value?
Nope, updates every time.
>Where does the string value come from?
I'm looking for info in NMHDR(address given in lParam) when WM_NOTIFY
message is sent.
I'm then converting the resulting 3 integers to an ASCII string with spaces.
The conversion works correctly, what I'm really trying to do is to save time
by not having to use the trace screen.
>How are you sending the message?
I'm intercepting the WM_NOTIFY message and then using SetWindowText to
update the caption
>Is it failing, or what?
Nope.
>Can you distill it down to a small example?
Nope, when I try with a smaller example it works perfectly 
One thing I have noticed; when the string is shown in the trace window,
after it has been *evaluated*, only the values of 32(space) and 48(0) have
their ASCII equivalent displayed beside them.
If I *directly* enter exactly the same string i.e.
my_string = {32,51,53,49...
it shows *all* the ASCII equivs. Is this starnge or is it something to do
with the trace procedure?
I'm very lazy at freeing allocated space, could this have anything to do
with my problem?
anyway, I'll catch you again tomorrow.
It's nearly 1:30 a.m. here in dear old Ireland.
Regards
Terry
>-- David Cuny
7. Re: Probably for David Cuny
- Posted by Robert Craig <rds at ATTCANADA.NET>
Jul 26, 1999
-
Last edited Jul 27, 1999
Terry Moriarty writes:
> I'm then converting the resulting 3 integers to an ASCII string with
> spaces. The conversion works correctly...
> my_string(on trace window)
> = {32,50,54,48,48,32,49,53,50,50,32,53,52,51,57,56,55,50}
> which translates to " 2600 1522 5439872"
> but the window title displays 2600 1511 5428861
> One thing I have noticed; when the string is shown in the
> trace window, after it has been *evaluated*, only the values
> of 32(space) and 48(0) have their ASCII equivalent displayed
> beside them. If I *directly* enter exactly the same string i.e.
>
> my_string = {32,51,53,49...
> It shows *all* the ASCII equivs. Is this starnge or is it
> something to do with the trace procedure?
I suspect that your conversion is producing results
which are *very* slightly off in some cases. When you
display the results in the trace window they are
rounded (to 10 significant digits), so they look ok,
but in reality they are not exact integers.
Later they get rounded *down*. That's why you get
digits that are 1 less than they should be in some cases.
If you show us the code that you are using for the
conversion maybe we can spot where the (slight) error
is creeping in.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
8. Re: Probably for David Cuny
Thanx Bernie, David and Robert, I'd forgot about sprint(). It's done the
trick.
For Robert,
The conversion I'd been using was
sequence my_inf
integer temp, string_address, ok
my_inf = {2600, 1522, 5439872} -- values filled during runtime
for i = length(my_inf) to 1 by -1 do
temp = my_inf[i]
if temp = 0 then
my_string = "0" & my_string
else
while temp != 0 do
my_string = ((((temp/10)-(floor(temp/10)))*10)+48) & my_string
temp = floor(temp/10)
end while
end if
my_string = " " & my_string
end for
string_address = allocate_string(my_string)
ok = c_func(SetWindowText, {window_handle[5], string_address})
Now who would use anything as complicated as sprint(my_inf) when they could
do something as simple the above 
Thanx again (I promise I'll check Library.Doc in future)
Terry
Robert wrote:
>I suspect that your conversion is producing results
>which are *very* slightly off in some cases. When you
>display the results in the trace window they are
>rounded (to 10 significant digits), so they look ok,
>but in reality they are not exact integers.
>Later they get rounded *down*. That's why you get
>digits that are 1 less than they should be in some cases.
>If you show us the code that you are using for the
>conversion maybe we can spot where the (slight) error
>is creeping in.
9. Re: Probably for David Cuny
Terry Moriarty writes:
> while temp != 0 do
> my_string = ((((temp/10)-(floor(temp/10)))*10)+48) & my_string
> temp = floor(temp/10)
> end while
Yes, this is what I suspected. You fell into the
very common trap of requiring floating-point
results to be perfectly accurate. The characters in
my_string will not necessarily all be perfect integers.
For example, (61/10 - floor(61/10)) * 10 will probably not
be *exactly* 1. It might be something like 0.99999999999999
which rounds down (later on) to 0. You could round
your digits, with something like digit = floor(digit+0.5)
to make them exact integers (or just use sprint()).
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
