Announcement

**ian mcallister** · 10 Jul 2000, 04:35 AM

Looks great but I can't get it to show results on my NT
machine at work.

(NT Server with service pack 6)

Any suggestions ?

------------------

**Semen Matusovski** · 10 Jul 2000, 04:51 AM

Under Win2000 (Rus) works fine.

------------------

**Florent Heyworth** · 10 Jul 2000, 04:54 AM

Got the same problem as Ian - can't output serach results to
the richedit control. I'm also running NT server SP 6

Cheers

Florent

------------------

**Borje Hagsten** · 10 Jul 2000, 07:39 AM

Strange - okay, to nail it down - Florence, Ian - what does the
path to the program look like on your machines? Have you installed
all files in the same folder? Can you get it to search and build
a list of results, meaning, is it only the loading of text into
rich edit that fails? What happens if you turn off word wrap?

I'm kind of fumbling around here, as you notice, because I have
no idea what is causing this and since it works fine on my own
machines, it's hard to know where to start looking..

------------------

**Florent Heyworth** · 10 Jul 2000, 08:00 AM

Hi Borje

everythings unzipped in g:\pows - all files are in the same
directory. The search goes fine and when I double-click on
the search results tab the function goes to LoadMessage
and correctly retrieves the text in LoadMessage's sBuf string
variable.

The problem is that at this point in the procedure the
SetWindowText hEdit API call does not set ANY text whatsoever:
tried it in LoadMessage. I tried calling SetWindowText in Pbmain
and that works fine before and after the Richedit control is
subclassed. The only problem is that the call does not display
any text when called from other routines (although SetWindowText
returns a positive value).

I haven't traced it back further yet. Will let you knwow as soon
as I find out more.

Cheers

Florent

------------------

**Borje Hagsten** · 10 Jul 2000, 08:12 AM

Thanks for the tips Florent - just noticed that the text for
use with SetWindowText isn't zero terminated. Could be why it
fails there. Try adding sBuf = sBuf & CHR$(0) right before
SetWindowText hEdit, BYVAL STRPTR(sBuf) in the LoadMessage
function and see if that does it.

------------------

**Florent Heyworth** · 10 Jul 2000, 11:18 AM

Hi Borje

I'd already tried to zero terminate the string but that didn't work.
I finally traced the problem to the SetWordWrap subroutine.

After the call to DeleteDC reDC, the richedit control would
refuse to show anything. I toyed with the idea of making reDC
global and deleting the device context on application release and
then looked for another way.

[EDITED]
Oops thought that was too good to be true... Will update a solution
as soon as I've tested it 8-)
[/EDITED]

Cheers

Florent

[This message has been edited by Florent Heyworth (edited July 10, 2000).]

**Florent Heyworth** · 10 Jul 2000, 12:44 PM

Hmmm, interesting

loading riched20.dll instead of riched32.dll everything works
fine (apart from the ScanLine routine where colors aren't set -
probably need to go about it a bit differently).

I'm going to check if I have a "dud" version of riched32.dll.

Cheers

Florent

------------------

**Florent Heyworth** · 10 Jul 2000, 01:17 PM

Even more interesting 8-)

my version of riched.dll is not a "dud" everything's okay there.

I've got a working version which works fine with both riched32.dll
and riched20.dll. Here it is (it works on Winnt 4.0 SP6) and
uses undocumented *features* of the richedit control (at least
I can't find any reference to them).

The following works fine including word-wrap although as far
as I know it *shouldn't*:

Anyone: for educational purposes I'm interested in finding out
if that works on your system(s). Pls mention the operating system.

Replace SetWordWrap with:

Code:

SUB SetWordWrap(BYVAL hDlg AS LONG)
 LOCAL lRes AS LONG, wdt AS LONG, tRect AS RECT

  CONTROL GET CHECK hDlg, %IDCHKWRAP TO lRes
  
  IF lRes THEN                               'If word wrap = on
     wdt = 0
     CALL SendMessage(hEdit, %EM_SETTARGETDEVICE, 0, wdt)
  ELSE
     wdt = 32000                             'should be enough..
     CALL SendMessage(hEdit, %EM_SETTARGETDEVICE, 0, wdt)
  END IF
  

END SUB

Cheers

Florent

------------------

**Borje Hagsten** · 10 Jul 2000, 03:56 PM

Well, it doesn't cause any GPF's, but on my machine, it wraps the
text at the first character. Maybe the error is caused by the fact
that the word wrap code is executed at startup?

I moved the initial word wrap setting in PBMAIN to the DlgCallback's
WM_INITDIALOG instead and added a small safety routine, like:

Code:

  pixPerX = GetDeviceCaps(reDC, %LOGPIXELSX)
  IF pixPerX = 0 THEN pixPerX = 96           'for added safety

Not that I think that particular piece of code ever fails, but
still - wouldn't be fun if it did and I end up with a division
with zero there.

Unfortunately, I managed to destroy the uploaded file, so I have
to upload it again. Not only that - my ISP has problems with the
FTP right now, so I can't say when the file will be up again.
On a good day it takes an hour - right now it may very well take
all night, so if anyone tries to download right now and the
file isn't there, just wait a couple of hours and try again.

(stupid me - started the upload right on to the target folder,
instead of using a subfolder and then move it into place once
the complete file is up..

------------------

**Florent Heyworth** · 10 Jul 2000, 04:08 PM

Hi Borje

I'm not suprised the code I posted doesn't work properly on
your machine - I'm just suprised that it does the trick on mine
(NT 4.0 SP6).

The problem with the text display is that once reDC is deleted
in SetWordWrap NOTHING gets displayed in subsequent calls.

A work-around would be to open the dc and make it a global
and delete it on exit but I didn't want to do that... oh well,
I can use the app now and that's the main thing.

It's very useful - thanks a lot Borje

Cheers

Florent

------------------

**Borje Hagsten** · 10 Jul 2000, 04:22 PM

Thank YOU, Florent, for all you help. I'll investigate this one
further and see if I can find anything about it at MSDN. Really
strange, because it shouldn't be necessary to keep the DC all
the time. Ah well, I have other problems to deal with right now,
like getting the file up on my server again, so that'll be
tomorrow's work..

------------------

**Borje Hagsten** · 10 Jul 2000, 07:08 PM

Okay, nailed it! Found the following regarding EM_SETTARGETDEVICE
at MSDN:

"If this function is successful, the rich edit control owns the
device context passed as a parameter. In that case, the calling
function should not destroy the device context."

So it turns out you were right, Florent. reDC must be Global (or
static) here - thank you very much for the help in finding this
out.

I'm uploading a fixed version right now - will be up in about an
hour, but if you already have downloaded it once, you can also
download a small 62 KB fix containing the new POFFS.BAS and EXE
files only from http://www.tolken99.com/pb/poffsupd.zip

------------------

**Erwin van de Wiel** · 11 Jul 2000, 04:51 AM

My colleague running poffs on NT4 with sp4 sometimes get a gpf.
Strange thing is that the search is going much faster on his machine.

He uses an identical computer as I use, but I use NT4 with sp6 and it doesn't give me any gpf.
I'm sorry that I don't have the time to debug the problem, but I quickly tried
to check out when it happened and this is the result:

All standard settings, but with both word wrap and color syntax enabled.
Then selecting an item in the second tab (Show result) gives the gpf.
It also happened only after a second or > search. When I disabled word wrap and/or
color syntaxing everything worked great.

Maybe some other user with same os and sp4 can reproduce the error.

------------------

**Lance Edmonds** · 11 Jul 2000, 05:36 AM

Borje, the project looks good! I've sent you a private email to discuss some minor change we'd like to see. Keep up the good work!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Florent Heyworth** · 11 Jul 2000, 06:40 AM

Erwan

I sent an e-mail to Borje about this but I don't think if he's had
time to look at the correction yet.

I traced the GPF to the asmUCASE subroutine. In subroutine
asmUCASE:

Code:

SUB asmUCASE(a$)
    
  'IF LEN(a$) = 0 THEN EXIT SUB '<- change this line
  'to line below:
  a$ = a$ & CHR$(0)             '<- Expressly terminate the string
 
  ! mov eax, a$            ; eax = pointer to string handle
  ! mov eax, [eax]         ; eax = pointer to string data

  BgnUpLoop:
     ! mov edx, [eax]      ; move current char into edx
     ! cmp dl, 0           ; compare dl, not edx because one char = 1 byte (eax = 4 byte)
     ! jne ContinueUpLoop
        ! jmp ExitUpLoop  ; jump out on end of string

  ContinueUpLoop:
     ! cmp dl, 97          ; CASE 97 TO 122
     ! jb NoDnChar         ;    if dl < 97  then next char
     ! cmp dl, 123
     ! jb MakeUpper        ;    if dl < 123 then make upper case and get next

     ! cmp dl, 224         ; CASE 224 TO 246, 248 TO 253 - extended ANSI characters
     ! jb NoDnChar         ;    if dl < 224
     ! cmp dl, 247
     ! jb MakeUpper        ;    if dl < 247
     ! cmp dl, 247
     ! je NoDnChar         ;    if dl = 247
     ! cmp dl, 255
     ! jb MakeUpper        ;    if dl < 255

     ! jmp NoDnChar        ; Done - next character

  MakeUpper:
     ! sub dl, 32          ; make uppercase
     ! mov [eax], dl       ; write changed char back into a$
     ! inc eax             ; get next character
     ! jmp bgnUpLoop

  NoDnChar:
     ! inc eax
     ! jmp bgnUpLoop

  ExitUpLoop:

END SUB

Cheers

Florent

[This message has been edited by Florent Heyworth (edited July 11, 2000).]

**Erwin van de Wiel** · 11 Jul 2000, 07:10 AM

Thanks florent.
I will change the source tomorrow and reply with
the results.

Greetz
Erwin.

------------------

**Borje Hagsten** · 11 Jul 2000, 08:34 AM

NT4 sure seems to be hard to please, doesn't it? I changed the
asmUCASE code to consider the string's length instead - at least
it feels a lot safer to do it like this.

A complete fix will be uploaded later on tonight, but in the meantime
maybe the following will help (I hope it works in NT4 too):

Code:

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
' asmUCASE routine
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
SUB asmUCASE(a$)
  LOCAL ln AS LONG
  ln = LEN(a$)             ' get string's len into ln
 
  ! cmp ln, 0              ; does the string have a length?
  ! je ExitUpLoop          ; exit if zero
 
  ! mov eax, a$            ; eax = pointer to string handle
  ! mov eax, [eax]         ; eax = pointer to string data
 
  BgnUpLoop:
     ! mov edx, [eax]      ; move current char into edx
     ! cmp ln, 0           ; exit when ln = zero
     ! jne ContinueUpLoop
        ! jmp ExitUpLoop   ; jump out on end of string
 
  ContinueUpLoop:
     ! cmp dl, 97          ; CASE 97 TO 122
     ! jb NoDnChar         ;    if dl < 97  then next char
     ! cmp dl, 123
     ! jb MakeUpper        ;    if dl < 123 then make upper case and get next
 
     ! cmp dl, 224         ; CASE 224 TO 246, 248 TO 253 - extended ANSI characters
     ! jb NoDnChar         ;    if dl < 224
     ! cmp dl, 247
     ! jb MakeUpper        ;    if dl < 247
     ! cmp dl, 247
     ! je NoDnChar         ;    if dl = 247
     ! cmp dl, 255
     ! jb MakeUpper        ;    if dl < 255
 
     ! jmp NoDnChar        ; Done - next character
 
  MakeUpper:
     ! sub dl, 32          ; make uppercase
     ! mov [eax], dl       ; write changed char back into a$
     ! inc eax             ; get next character
     ! dec ln              ; decrease the ln (length) counter
     ! jmp bgnUpLoop
 
  NoDnChar:
     ! inc eax
     ! dec ln
     ! jmp bgnUpLoop
 
  ExitUpLoop:
 
END SUB

------------------

**Florent Heyworth** · 11 Jul 2000, 09:25 AM

Hi Borje

this works fine and is faster 8-)

Cheers

Florent

------------------

Announcement

POFFS v1.2 - completed!

POFFS v1.2 - completed!

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment