Memoedit() not word wrapping

618 views
Skip to first unread message

Tim Jacob

unread,
Jul 29, 2015, 9:07:32 AM7/29/15
to harbou...@googlegroups.com
I'm running Harbour 3.2.0dev (r1504011259).

Memoedit() does not word wrap.

Does anyone know if a later build has addressed this?
Many thanks

--
Jolly Farmer: Tim Jacob - IT
email: tja...@jollyfarmer.com
web: www.jollyfarmer.com
tel: 506-325-3850 | fax: 506-325-3890
"Integrity, Quality, & Reliable Service Since 1967"

Massimo Belgrano

unread,
Jul 29, 2015, 1:26:59 PM7/29/15
to harbou...@googlegroups.com
post your sample so i try

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire 

Juan Francolino

unread,
Jul 29, 2015, 1:33:40 PM7/29/15
to harbou...@googlegroups.com
Hi,

I have the same problem.

  cMemo:=Memoedit(1,10,20,70)

Wrap in pos 71


Regards,


Juan

Massimo Belgrano

unread,
Jul 29, 2015, 1:53:30 PM7/29/15
to harbou...@googlegroups.com
If you have a sample with "text" var compiled  and keyboard i can run whitout reivent whatd do you want
afaik word wrap is down returning in udf   ME_WORDRIGHT 
http://www.oohg.org/cl53/ng69599.html


Func main
    x_string= "sample text sample text 1 sample textsample 2 textsample text 3 sample text 5 sample textsample tex6 tsample text"
    // keyboard x_string
    memoEdit( x_string, 1, 1,20 , 70)



Tim Jacob

unread,
Jul 30, 2015, 6:42:41 AM7/30/15
to harbou...@googlegroups.com
The problem may be in the Mingw compiler.

I tried the newest nightly build as of yesterday (r1506261250), and there was no difference.
Then downloaded the source and compiled Harbour with BCC 5.5.
When I recompiled my application with this "Borlandized" Harbour, word wrap worked as it should have.

Massimo Belgrano

unread,
Jul 30, 2015, 10:54:38 AM7/30/15
to harbou...@googlegroups.com
in my sample works fine Mingw Borland seem hidden problem in source code
bat you dont give right sample i stop follow post 

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Claudia Neumann

unread,
Aug 4, 2015, 7:52:31 AM8/4/15
to harbou...@googlegroups.com
Hi all,

yes, I see that as well
(Linux, Harbour Make (hbmk2) 3.2.0dev (r2015-07-27 16:41) )

You can reproduce the false behaviour if you use memoedit() with width=63:

write:
sssssssssssssssssssssss dddddddddddddddddddddddddddddd fff ggg
kkkjjjhhh

you have to write it, don't copy and paste it.

Go to the end of the first line and write an "a" (without quotation marks).

You should see:
sssssssssssssssssssssss dddddddddddddddddddddddddddddd fff ggg
a kkkjjjhhh

but with new version you see:
sssssssssssssssssssssss dddddddddddddddddddddddddddddd fff ggg
akkkjjjhhh

The same happens if you type pp before the ggg:

You should see:
sssssssssssssssssssssss dddddddddddddddddddddddddddddd fff
ppggg akkkjjjhhh


But you see:
sssssssssssssssssssssss dddddddddddddddddddddddddddddd fff
ppgggakkkjjjhhh

So wordwrap is not working as before in memoedit.

Best regards

Claudia

Thiarnron

unread,
Sep 8, 2015, 3:57:35 PM9/8/15
to Harbour Users
memoedit has a problem as of Harbour 3.2
I'm using again 3.0 that does not have that problem

Just test it :

Make this small program :

ntekst=""
ntekst=MEMOEDIT(ntekst,8,13,16,73)

Then compile it with 3.0, run it, type a to l 6 tmes with a space between (aaaaaa bbbbbb cccccc etc ....)
Then compile it with 3.2, and do the same test

I attach an image of both results ... 3.0 does the job fine, 3.2 has a problem with wordwrap (even 1 "k" is missing (not displayed)....)

Since my emailaddress of my google account is no longer working (since lavabit.com stopped it services, you can not contact me anymore at that address, but you can contact me at clement...@hotmail.be



Op donderdag 30 juli 2015 16:54:38 UTC+2 schreef Massimo Belgrano:
memoproblem.jpg

Massimo Belgrano

unread,
Sep 9, 2015, 6:06:27 AM9/9/15
to harbou...@googlegroups.com
Can you test with clipper 5.2/5.3?

Kristian

unread,
Sep 29, 2015, 10:30:40 AM9/29/15
to Harbour Users
Hi all,

I am encountering problems too. This is a converted clipper application where <Tab> is used to advance through a mask with pop-down arrays, text fields, and memo fields. I used MEMOEDIT() to edit the latter, and a UDF to handle the Tab-key such that the changes were saved and the edit terminated.

Here are the differences to the previous behavior in clipper:
 - soft carriage returns are inserted as the visible character 141, it does not vanish when line breaking changes.
 - also, it is saved into the memo field and will cause e.g. LaTeX to fail when it is encountered.
 - the <Tab> keystroke is handled as intended (leave the edit and proceed to the next field) but it is inserted at the current cursor position before leaving MEMOEDIT. Thus, if the Memo is opened again, there are four spaces inserted.
 - when I hit the right column and the line is broken, the entire text window is shifted to the left so that the leftmost character in each line is hidden. I need to strike <Home> or such to cause the window content to shift back.

Now, there are some workarounds:
 - I can live with chr141, as I can edit hard carriage returns instead of using automatic line breaks.
 - I can use MEMOTRAN() to remove chr141 before printing to a file.
 - and the last point is no big deal; I just wanted to mention it.
BUT: I always need to go to the end of the memo field, otherwise four spaces will be inserted at the current cursor position. And of course this will cause line breaks I avoided by editing hard carriage returns myself. It is especially annoying if I am just tabbing through the fields and need to move the cursor to the end although I did not intend to edit the field at all. And I am appending four spaces each time I leave a memo field.

So I am wondering whether this can be repaired.

An alternative could be HBEdit which I have seen mentioned in other threads. Unfortunately, I have not found any documentation on this command. Where do I find it? It may be a more modern alternative to MEMOEDIT, but for these short memo fields that primitive editor is just fine, and I am not ambitious to make major changes.

Thanks,
Kristian

elch

unread,
Oct 2, 2015, 9:32:23 AM10/2/15
to Harbour Users
Hi Kristian,

the by Thiarnron reported problem i never could replicate, so can not confirm.

I followed even Massimo's wish to compare against Cl*pper, looked well at me.


---
 - also, it is saved into the memo field and will cause e.g. LaTeX to fail when it is encountered.
...

So I am wondering whether this can be repaired.
 

Wotrd-Wrap is per default ON, will cause CHR141 (soft-CR) insertion, can be disabled like here described:

http://x-hacker.org/ng/53guide/ng6c7b8.html

http://x-hacker.org/ng/53guide/ng69599.html

I would suggest doing so right with ME_INIT ( aka memoedit startup ) if you don't wont such.


Please try to prepare a minimal example, then i may can help further -- even up to fixing a problem if we find one ...

Would like to see at least your <userfunc>, but a 'full' snippet with a "PROC main" is better.


best regards

Rolf

Przemyslaw Czerpak

unread,
Oct 6, 2015, 9:38:21 AM10/6/15
to harbou...@googlegroups.com
Hi Kristian,

Please test current Harbour code.
If you will find some problems then please report it with
self contain example so I can test it in Cl*pper and compare
Harbour and Cl*pper behavior.

best regards,
Przemek
Message has been deleted

Massimo Belgrano

unread,
Oct 9, 2015, 7:05:57 AM10/9/15
to harbou...@googlegroups.com
I confim that clipper 5
Immagine incorporata 1
Instead harbour 3.2 OF 29.08.2015
Immagine incorporata 2
Last harbour is like clipper
Immagine incorporata 1

#INCLUDE "MEMOEDIT.CH"
#INCLUDE "INKEY.CH"
PROC MAIN()
    LOCAL A
     CLS
     Name="TEST1"+space(1)+CHR(13)+CHR(10)  + "TEST2"+space(1)+CHR(13)+CHR(10) + "TEST3"+space(1)+CHR(13)+CHR(10) + "TEST4"+space(1)+CHR(13)+CHR(10) + "TEST5"+space(1)+CHR(13)+CHR(10) +"TEST6"+space(1)+CHR(13)+CHR(10) + "TEST7"+space(1)+CHR(13)+CHR(10)  + "TEST8"+space(1)+CHR(13)+CHR(10)+ "TEST9"+space(1)+CHR(13)+CHR(10)
     Name=NAME +"TEST11"+space(1)+CHR(13)+CHR(10)  + "TEST12"+space(1)+CHR(13)+CHR(10) + "TEST13"+space(1)+CHR(13)+CHR(10) + "TEST14"+space(1)+CHR(13)+CHR(10) + "TEST15"+space(1)+CHR(13)+CHR(10) +"TEST16"+space(1)+CHR(13)+CHR(10) + "TEST17"+space(1)+CHR(13)+CHR(10)  + "TEST18"+space(1)+CHR(13)+CHR(10)+ "TEST19"+space(1)+CHR(13)+CHR(10)
CY=MLCount(NAME,78)+1
     cX := 0
     cY := MLCount(Name,78)+1
     pX := 0
     IF MLCount(Name,78)+1 <= 17
     pY := MLCount(Name,78)+1
      ELSE
   pY := 17
      ENDIF
 // KEYBOARD "TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1) +"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)+"TEST"+space(1)
    
 NAME := MemoEdit(NAME,5,1,20,78,.T.,"TastoVis2",78-1,8, cY,cX,pY,pX)  // TastoVis2

      //NAME := MemoEdit2( NAME, 5, 1, 20, 78, .T., "m_func", 78 ,8,CX,CY,PY,PY)

return

FUNCTION TastoVis2( nMode,R,C)
 Local nKey:=lastkey(),NRET
   IF nMode == ME_INIT
      RETURN ME_DEFAULT
   ELSEIF NMODE=ME_IDLE
      @Maxrow(),2 say ltrim(str(c))
      Return ME_DEFAULT
   ELSEIF nMode == ME_UNKEY .OR. nMode == ME_UNKEYX
 IF nkey == K_ESC .OR. nkey == K_CTRL_W
         RETURN nkey
      ENDIF
        //RETURN NRET
      // ENDIF
   ENDIF
   Return ME_DEFAULT

2015-10-06 18:03 GMT+02:00 Kristian Schilling <schi...@nanolytics.de>:
Hi Przemek, hi Rolf

thank you for your responses. I am grateful for your willingness to follow this up.

I will be on a business trip the next two days, and I may not find the time to put an example together on Friday. Unfortunately, my main job is another...

But I will do this as soon as I can and then post it officially.

Thanks again,
Kristian
--
Nanolytics
Gesellschaft fuer Kolloidanalytik mbH
Dr. Kristian Schilling

Am Muehlenberg 11
D-14476 Potsdam
Tel: +49 331 5818360
Fax: +49 331 5818361
e-mail: schi...@nanolytics.de
Internet:  www.nanolytics.de
_______________________________________________
Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

--- You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

francolino

unread,
Oct 9, 2015, 5:25:55 PM10/9/15
to harbou...@googlegroups.com
Hi,

Harbour worked well until there was a change a few months ago.

I can not say that version stopped working properly.


Regards,

Juan Francolino

Przemyslaw Czerpak

unread,
Oct 12, 2015, 7:38:18 AM10/12/15
to harbou...@googlegroups.com
Hi Massimo,

Please make tests with current Harbour code.
If you find differences to Cl*pper then please inform me.
Current Harbour with the example below gives the same
results as Cl*pper 5.2

best regards,
Przemek
> Delta Informatica S.r.l. (*Cliccami per scoprire
> <http://www.deltain.it/mbelgrano>*)

Massimo Belgrano

unread,
Oct 12, 2015, 9:23:44 AM10/12/15
to harbou...@googlegroups.com
I Confirm that last harbour works like clipper
Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire 

Kristian

unread,
Oct 12, 2015, 11:26:08 AM10/12/15
to Harbour Users
Hi Przemek, hi Rolf,

I have now constructed a reduced example of the problem. This code used to work in Clipper. It may not be very elegant, so to avoid confusion, here are some remarks: the memo fields are elements of an input mask with simple text and numeric GETs, ACHOICE type popdowns, and memo fields. The user is supposed to be able to proceed from one input field to the next by pressing TAB (or skipping to the recent field with SH_TAB, respectively). The ESC key shall leave the GET at any point. The latter is accomplished by the GetReadQuickExit() function which is evaluated before entering the next Getlist element. The MemoReader calls a "_getmemokeys" UDF which handles the TAB and SH_Tab  events; it is also supposed to maintain a stack for further special events, depending on the mask that called MemoReader(). But this has become complicated with harbour where a lot of functions lie on the Callstack that were not there with clipper. I have left it in there to indicate its function.

I apologize that this is still a rather long example, but I have done my best to reduce it as much as possible.

I am attaching four screenshots to demonstrate what happens:
Pic1: This is the display after starting the program. The first Memoedit displays and is waiting for input.
Pic2: The screen after striking TAB two times. Insert mode is off. So far, so good, the cursor went to the second Memoedit upon the first TAB, and it jumped back to the first Memoedit after the second TAB.

But now: after striking INS, switching to insert mode:
Pic3: Inserting text works out ok if I insert characters in the beginning of the first memoedit. The text will scroll on while I insert test. This is what others tested. However, removing the text with Backspace will delete the text, but not cause the following text to scroll back.
AND:
Pic4: This is what happens when I TAB to the second Memoedit and back to the first with INS on. The TAB does cause the cursor to jump to the other Memoedit as intended, but the TAB is executed within the Memoedit before leaving it. This caused the word "please" after the inserted text to shift by fur spaces, and the first word in the second Memoedit as well. In addition, the soft carriage returns were inserted as the visible char 141 and they need to be deleted by hand. They will print out, and they will remain at obsolete positions. After TABbing some more, the text will be a complete mess.

As said, this used to work in Clipper, and I would be happy to maintain this code. Your efforts are appreciated.

And here is the example:

# include "getexit.ch"
# include "inkey.ch"
# include "setcurs.ch"
//# include "box.ch"

FUNCTION Main()
LOCAL vMemo := "Please pay by wire transfer. Please instruct your bank to debit you with all charges, also those generated by the receiving bank in the country of destination."
LOCAL vMemo2 := "We do not like people who do not pay timely and completely. We have friends who do not like this either. Think twice before considering getting know our friends."
LOCAL nOben := 1
LOCAL nLinks := 1

clear screen
SET SCOREBOARD OFF

@ nOben+2, nLinks+9 TO nOben+10, nLinks+66 DOUBLE       // simple version for demo; usually Memoreader() will do the job
@ nOben+22, nLinks+14 GET vMemo  SEND reader := {|x|MemoReader(x, nOben+3, nLinks+10, nOben+9, nLinks+65, "Praeambel editieren" )} VALID GetreadQuickExit()

@ nOben+12, nLinks+9 TO nOben+20, nLinks+66 DOUBLE
@ nOben+23, nLinks+14 GET vMemo2  SEND reader := {|x|MemoReader(x, nOben+13, nLinks+10, nOben+19, nLinks+65, "Nachruf editieren" )} VALID GetreadQuickExit()

ReadModal ( Getlist )

RETURN .T.


FUNCTION MemoReader ( oGet, nTop, nLeft, nBottom, nRight, cTitle )
// memo reader use for memoedit in gets
// if cTitle is specified, MemoReader will draw a box around the Memoedit field and display the
// Title in the top frame. cTitle == "" will draw the box with no title. cTitle == NIL will draw no box.
MEMVAR Getlist
LOCAL buf
LOCAL e_state := GE_DOWN                // the exit state for the get
LOCAL cFirstGet := Getlist[1]:name
LOCAL cLastGet  := Getlist[LEN(Getlist)]:name
LOCAL nLastKey, nNextKey
LOCAL saveColor := SETCOLOR()
LOCAL saveCursor:= SETCURSOR ( IF(ReadInsert(), SC_INSERT, SC_NORMAL) )
LOCAL lDrawBox
LOCAL OldScreen, OldColor

PRIVATE updated := .F.

lDrawBox := IIF ( cTitle == NIL, .F., .T. )
IF lDrawBox
// omitted for demo version
  ENDIF

IF ( getPrevalidate(oGet) )
//  SetColorEnhanced ( saveColor )
  oGet:setfocus()
  buf := MEMOEDIT ( oGet:varget(), nTop, nLeft, nBottom, nRight, .T., "_getmemokeys" )
  nLastKey := LASTKEY()
  nNextKey := NEXTKEY()
  IF ( nLastKey == K_ESC )
    oGet:undo()
    updated := .F.
    e_state := GE_ESCAPE
   ELSE
    oGet:varput(buf)
    DO CASE
      CASE nNextKey == K_UP
        INKEY()
        e_state := GE_UP
//      CASE nNextKey == K_SH_TAB
      CASE nNextKey == 15                       // kludge: leider wird aus 271 eine 15, damit CTRL-O statt SH_TAB
        INKEY()
        IF oGet:name == cFirstGet
          e_state := GE_BOTTOM
         ELSE
          e_state := GE_UP
          ENDIF
      CASE nNextKey == K_DOWN
        INKEY()
        e_state := GE_DOWN
      CASE nNextKey == K_TAB
        INKEY()
        IF oGet:name == cLastGet
          e_state := GE_TOP
         ELSE
          e_state := GE_DOWN
          ENDIF
      CASE nNextKey == K_PGDN
        INKEY()
        e_state := GE_WRITE
      CASE nNextKey == K_RETURN
        INKEY()
        e_state := GE_WRITE
      OTHERWISE
      ENDCASE
    ENDIF
//  SetColorInactive ( saveColor )
  @ nTop, nLeft CLEAR TO nBottom, nRight
  MEMOEDIT ( oGet:varget(), nTop, nLeft, nBottom, nRight, .F., .F. )
  IF ( updated )
    updated (.T.)
    ENDIF
  oGet:exitstate := e_state
  oGet:killfocus()
  SETCOLOR(saveColor)
  ENDIF

IF lDrawBox
//...  restoreRectangle ( OldScreen )
  ENDIF
SETCURSOR ( saveCursor )

RETURN NIL



FUNCTION _getmemokeys ( mode, line, column )
// udf to handle idle state or unassigned key in memoedit
// must be public because memoedit calls it as a macro (ecch!)
// exits on [Up] in top line or [PgDn] or [F10] anywhere
MEMVAR updated
MEMVAR vSprache
STATIC prevline := 0
LOCAL aInstructions := { }
LOCAL cBackCallFunction
LOCAL cInsert := ""
LOCAL nKey:= LASTKEY()
LOCAL aStack := {}
LOCAL nStackCount := 1

PRIVATE returnvalue := 0

DO WHILE ! EMPTY ( PROCNAME(nStackCount) )          // build this stack as it has been difficult since Harbour
  AADD ( aStack, PROCNAME(nStackCount) )            // to know exactly how far up the stack a certain calling
  nStackCount++                                     // function might be
  ENDDO

AADD ( aInstructions, "MemoUDFB1" )
IF mode == 3                                // kludge!! Else K_TAB will stay LASTKEY() and
  KEYBOARD CHR ( K_LEFT )                   // Memoedit terminates immediately with Mode = 0.
  ENDIF
IF ( mode < 3 )
  DO CASE
    CASE ( mode == 0 .AND. LASTKEY() == K_PGDN )
      KEYBOARD chr(K_CTRL_W)
    CASE ( LASTKEY() == K_TAB )
      KEYBOARD chr(K_CTRL_W) + chr(K_TAB)
    CASE ( LASTKEY() == K_SH_TAB )
      KEYBOARD chr(K_CTRL_W) + chr(K_SH_TAB)
    CASE ( nKey == K_ESC )
      returnvalue := K_ESC
    CASE ( nKey == K_CTRL_W )
      returnvalue := K_CTRL_W
    CASE ( nKey == K_CTRL_INS .AND. ASCAN ( aStack, {|x| x == "ATEDITDATEN" } ) != 0 )      // exceptions definieren
      cBackCallFunction := aInstructions[1]
      cInsert := &cBackCallFunction ()
    CASE ( nKey == K_DEL .OR. nKey == K_BS )
      updated := .T.
    CASE ( nKey >= 32 .and. nKey <= 255 )
      updated := .T.
    ENDCASE
  ENDIF
RETURN (returnvalue)



FUNCTION GetreadQuickExit()
IF LASTKEY() == K_RETURN
  READKILL (.T.)
  ENDIF
RETURN .T.

Pic1.jpg
Pic2.jpg
Pic3.jpg
Pic4.jpg

Massimo Belgrano

unread,
Oct 12, 2015, 11:52:07 AM10/12/15
to harbou...@googlegroups.com
I recompile using harbour
the press tab,ins,tab
Immagine incorporata 2

Przemyslaw Czerpak

unread,
Oct 12, 2015, 12:35:27 PM10/12/15
to harbou...@googlegroups.com
Hi Kristian,

I have just compiled your example with Clipper 5.2 and Harbour
and in both cases it works in the same way as you described.
TAB is inserted to edited text. But it's standard CA-Cl*pper
MEMOEDIT() behavior. Also deleting text does not rollback text
formatting until you press CTRL+B (or ALT+B if you are using
GT without extended key code support). Here Harbour is also
compatible with Clipper.
Playing for a while with your test code I found only one
difference to CL52. In Cl*pper MEMOEDIT() after CTRL+W always
returns formatted text with soft CRs even if it was not modified
bu user (you can see it in bottom lines after initial TAB before
you made any modifications in text) but Harbour does the same
only if text was modified. If nothing was changed then Harbour
returns original text. It's rather minor difference and not
related to problems you want to present (BTW Harbour confirms
documented in NG Clipper behavior here) but of course I'll fix
soon.
Anyhow I do not see any other differences to Clipper in your
test code. Just test it with Clipper. If I'm missing something
then please inform me.

best regards,
Przemek

Przemyslaw Czerpak

unread,
Oct 12, 2015, 12:36:04 PM10/12/15
to harbou...@googlegroups.com
On Mon, 12 Oct 2015, Massimo Belgrano wrote:

Hi Massimo,

> I recompile using harbour
> the press tab,ins,tab
> [image: Immagine incorporata 2]

With CL5.2 I have exactly the same results.

best regards,
Przemek
Message has been deleted

elch

unread,
Oct 12, 2015, 2:14:27 PM10/12/15
to Harbour Users
Hi,

deleted my last post, as i missed latest memoedit change in Harbour, sorry ...

best regards
Rolf

Kristian

unread,
Oct 13, 2015, 3:56:33 AM10/13/15
to Harbour Users
Hi Przemek,

I apologize for overlooking that, as you have correctly stated, TABbing in insert mode causes exactly the same result in clipper. But I do think there is a difference which I mentioned in the fourth point I made. I am attaching three screenshots for demonstration.
Pic1: This is the result in clipper after TABbing four times in insert mode. I have jumped between the two edits twice, each time four spaces have been inserted in the beginning.
Pic2: When I do the same with harbour, lots of visible characters 141 are inserted.
Pic3: After removing the initial spaces again and hitting CTRL-B or ALT-B, the original text is restored in clipper (not shown). In harbour, all the characters 141 remain; they need to be removed by hand until reformatting will have the desired result.

Of course the TAB problem is something I need to fix in my code; somehow I have not managed to "catch" the TAB before it is inserted into the text which I never intended. But the problem with char 141 occurs with any other text insertion as well. I can avoid this, as suggested by Rolf, by deactivating wrap mode, but I find it convenient and would like to maintain it.

And thanks to everyone for your prompt replies.

Kind regards,
Kristian
Pic1.jpg
Pic2.jpg
Pic3.jpg

Przemyslaw Czerpak

unread,
Oct 13, 2015, 8:15:16 AM10/13/15
to harbou...@googlegroups.com
Hi Kristian,

Are you using current Harbour code with unmodified example you sent?
I'm trying to replicate the problem with SoftCRs but I cannot.
Can someone else confirm that this problem exists in current
Harbour 3.2 taken from https://github.com/harbour/core.git?
Current code uses hb_mlEval() to format text and this function
removes SoftCRs so I do not see any way they can appear in edited
text.

best regards,
Przemek

Kristian

unread,
Oct 13, 2015, 8:34:14 AM10/13/15
to Harbour Users
Hi Przemek,

I confirm that this is the code I posted, with no modifications.

The Harbour version I use is a nightly build I downloaded last weekend.

Thank you for your efforts.
Kristian

elch

unread,
Oct 13, 2015, 8:52:25 AM10/13/15
to Harbour Users

Hi Kristian,


ups, the nightly build is a month old, the memoedit changes just some days.

I'll make an extra note about, should be soon fixed ...


---

Another tip about: .. Else K_TAB will stay LASTKEY()


In the former "C-lipper T-ools" was a function called: SetLastKey().

That is what you want, much better than to push a new key with KeyBoard.

I intense use this function collection, nearly all also available in Harbour.

So you have two choices, one is to use "native' Harbour:

hb_KeySetLast( nKey )


the other way is to use the CT [clipper tools] function:

SetLastKey( nKey )

This case you have to link the contrib: hbct to your application by just easy adding:

hbct.hbc

to your hbmk2 command line/ .hbp make file. Both functions do internally the same ...

Please note that you can use zero: SetLastKey( 0 )



---

Catching an InKey before it is applied to the MemoEdit text is tricky.

Possible again with a function from the Clipper Tools:

SetKxLat(), which will modify the key codes of TYPED! inkeys.

http://www.x-hacker.org/ng/tools1-3/ng1c8af.html


Try:

#include "ctscan.ch"

..


SetKxLat( KS_TAB, KS_ALT_T )

MemoEdit( .... )

SetKxLat( KS_TAB )


and then in _getmemokeys() you check for K_ALT_T as result for a typed! K_TAB.

Please note, that SetKxLat() uses key-codes out of the ctscan.ch with a "KS_" prefix,

but in you <userfunc> for the memoedit you check and test for 'classic' key-codes.


Don't forget to reset such modifications soon as possible, to avoid 'funny behavior' of your application ;-)

The target key shell be one else not used in application, to not disturb/ de-activate app logic.

And note, that above removes the possibility to really TYPE a TAB.


best regards

Rolf

Przemyslaw Czerpak

unread,
Oct 13, 2015, 9:07:58 AM10/13/15
to harbou...@googlegroups.com
On Tue, 13 Oct 2015, Kristian wrote:

Hi Kristian,

> I confirm that this is the code I posted, with no modifications.
> The Harbour version I use is a nightly build I downloaded last weekend.

This is old version which does not contain fixes I committed about two
weeks ago. Please take current code from GITHUB and rebuild Harbour.
In this version all should work just like in Cl*pper.

best regards,
Przemek

Kristian

unread,
Oct 15, 2015, 9:56:19 AM10/15/15
to Harbour Users

This is old version which does not contain fixes I committed about two
weeks ago. Please take current code from GITHUB and rebuild Harbour.
In this version all should work just like in Cl*pper.

Hi Przemek,

I got the current sources from GITHUB, unzipped core-master.zip into the hb32 directory, and recompiled from a DOS prompt where I had included the MINGW\bin directory into the PATH. Compiling the program now gives a version, as you stated, that behaves like Clipper MEMOEDIT(); the 141 chars are gone. Thank you very much. Nevertheless, please have a look at the screenshot (there appears to be no log of the harbour build process, at least I have not found any) and tell me whether the error messages in the end are critical, or what I have done wrong.

Thanks Rolf for your advice on how to catch special characters like <TAB> before they are processed by Memoedit(). I will check this out; without your help I would never have found these tools.

And I would still be grateful if you pointed me to documentation on hbEdit that was mentioned on another thread. It might be a good option for future applications if it is superior to Memoedit().

Thanks to all,
Kristian
makewin.jpg

elch

unread,
Oct 15, 2015, 2:40:46 PM10/15/15
to Harbour Users

Hi Kristian,


something went wrong building Harbour, it failes in your screenshot with building the 'contribs' [during build process called 'projects'].

Contribs are many libraries like mentioned ClipperTools is one, which makes Harbour so powerful:

for SQL access, PDF create, barcodes, sending eMail etc etc.


As first quick assumption: looks like something is wrong with the PATH to the MinGW C compiler.


If no success, do following:

in Windows you can re-direct the output in the [DOS] command window, instead to screen into a file, by adding to the end of the command:

> log.txt 2> err.txt

With attaching that (zip-ped packed) result plus info about your PATHs and how you set them,

start a new thread, have nothing to do with memoedit.



And I would still be grateful if you pointed me to documentation on hbEdit that was mentioned on another thread. It might be a good option for future applications if it is superior to Memoedit().
 
You mean hb_edit() out of the hbmisc contrib ??
That's even new to me, looks like a very different implementation of a text editor, still not used/ needed.


MemoEdit() [in src/rtl/memoedit.prg] in native Harbour inherits 'basic' HBEditor class & methods, defined in src/rtl/teditor.prg.

So you also can do to create a personalized 'text editor'.

I admit this is a bit advanced task, needs a bit knowledge of OO [object orientated] programming style and what Harbour does in its' HBEditor methods.


best regards

Rolf

Reply all
Reply to author
Forward
0 new messages