BACKSPACE event ON LARGE editor

[sheeker]

Hi,
How do I override the BACKSPACE event ON the LARGE editor?.It seems the
backspace event is applied before any trigger on this event is able to stop
it from happening.

I tried SELF:EDIT-UNDO() but this is still allowing to delete the last typed character.
is there any other way I can trap the event before the character is deleted.

Thank you,
Sheeker

 

[Cringer]

It's not a solution, rather a workaround, but you could maybe store the value of the editor using the any printable trigger, then on backspace, set the value of the editor to be what it was before the backspace was hit.

 

[tamhas]

All of which sounds very user unfriendly...

 

[TomBascom]

I certainly agree that it is ugly, ugly, ugly. And a terrible thing to do to a user. But are you saying that this doesn't work?

define variable c as character no-undo view-as editor inner-lines 5 inner-chars 40.

form c with frame a.

on "backspace" of c in frame a do:
  message "BS!".
  return no-apply.
end.

update c with frame a.

return.

 

[tamhas]

But are you saying that this doesn't work?

Not me!

BTW, in addition to being unfriendly, it seems like a good way to guarantee a lot of calls to support.

 

[rusguy]

it seems like it only fails to work with "large" editor. This code fails (tested on v9.1d and v10.2b):

define variable c as character no-undo 
  view-as editor inner-lines 5 inner-chars 40 LARGE.
form c with frame a.
on "backspace" of c in frame a do:
  message "BS!".
  return no-apply.
end.
update c with frame a.
return.

It really needs some workaround, like the one Cringer suggested

 

[TomBascom]

10.2A, Linux works like a charm.

What platform are you guys that are having trouble using?

 

[rusguy]

windows, "large" attribute doesnt apply to the *nix gui.

 

[sheeker]

Hi guys,

I appreciate your responses.. I am using LARGE EDITOR on a progress GUI window.. which is running on window xp .

I am still expecting an advice on this. any suitable work-around will do..

thanks,

 

[TomBascom]

windows, "large" attribute doesnt apply to the *nix gui.

I know. (It does compile under UNIX though...) I asked to make sure that it is a platform specific issue.

As I recall (and to the degree that I can be trusted to comment on windoze) the large editor is really slickedit under the covers.

It seems to me that there is now a nice simple test case that could be forwarded to tech support.

Beyond that the ON ANY-PRINTABLE suggestion seems promising.

Or perhaps the original poster should step back and explain why this very strange request is needed and maybe someone could suggest a different way to solve the underlying business problem.

 

[tamhas]

Indeed, the first question here ... other than the intellectual curiosity of "why can't I do that" is "why would you want to to it in the first place". Perhaps there is a lingering "bug" here where something doesn't behave as it should, but there is a temptation to think that the reason it hasn't been noticed or fixed is that it is a wrong thing to do ... and, if there is a sound business purpose here, that an entirely different solution is more to the point.

 

[rusguy]

This is the quick and dirty code that could work as a workaround

define variable c as character no-undo 
  view-as editor inner-lines 5 inner-chars 40 LARGE.
form c with frame a.
def var cval as character no-undo.
on "backspace" of c in frame a do:
  def var i as int no-undo.
  i = self:cursor-char.
  self:screen-value = cval.
  self:cursor-char = i.
  return no-apply.
end.
ON "any-printable" of c in frame a 
DO:
  def var i as int no-undo.
  i = self:cursor-char.
  cval = substr(self:screen-value, 1, self:cursor-char) + 
          last-event:label + substr(self:screen-value, self:cursor-char + 1).
  RETURN.
END.
update c with frame a.
return.

As for the business need for this request – the only thing that comes to mind is the need to have some kind of a comments box that displays all previous comments and doesn’t allow removing of the old ones. It seems to me that something like this could be done differently, without the need to trap the backspace.

 

[TomBascom]

That's what I was thinking too. A simple "append comment" function which lets the new comment be created in its own editor (perhaps overlaid on the existing editor in order to make them look like a single body of text) should do the trick.

 

[sheeker]

thank you for the responses.

The solution I am looking is for the business need. The editor will have some db-fields along with the text and I don't want user to delete those db-fields partialy. So the question is why can't I override the backspace event. I was able to suppress all the events except backspace event. this event is suppressible if it is a regular editor. it looks to me that it is a progress bug with large editor.
I see some other events also behaving differently in large editor

the solution rusguy provided will work only if we type the printable key before backspace. There are multiple to add text in the editor.. like paste/load etc..






thanks,

 

[tamhas]

Really, the right answer here is to divide the display into the non-editable part and the editable part. You will be less frustrated trying to program it and the user will be less frustrated trying to use it.

 

[rusguy]

You should definitely split it up - this is not very user friendly to allow users to type something in without allowing deleting their misspelled mistakes.

 

[zee]

You should definitely split it up - this is not very user friendly to allow users to type something in without allowing deleting their misspelled mistakes.

Exactly what I was thinking. If you insist on doing what you're trying to do here, you would also have to consider other possibilities to achieve the same result (e.g., pressing the left arrow key and then pressing delete). Ugly, ugly, ugly.

 

[sheeker]

let me explain it more clearly.. The text will look like as follows:

------------------
My name is <|cutstomer.name|> . This is a customer from city <|customer.city|> . the end of the text.

------------------------
Note:- the text (db field) enclosed within <> are not typed by the user but inserted from a selction list that contains all the fields in the customer table. I don't want user to mess up these enclosed fields . however they can delete those field fully. basically the whole text within bracket sould be treated like a single character.

I have controlled all the possible keyboard/mouse events. and looking a better way to handle this backspace event bug.


I hope, i am able to explain the business need . I have seen this in many of the .net applications.

 

[tamhas]

Then your problem is not the backspace key. There are many ways to navigate to the area between <> and do deletions. If you are going to do this, then you really need to notice if you are between <> on any key press and act accordingly. E.g., cursor left or right should jump to right across the field, delete anywhere in the field should delete the whole field, etc.

 

[TomBascom]

And quite aside from the usability concerns -- do you really need the LARGE editor for this?