TextArea issues

Targets Windows
1

The TextArea control in Windows has some serious issues. I’m building a grid based on a canvas, using some container controls for user input.

I made a video and some screenshots demonstrating some of the stuff I encountered (so far)
http://gorgeousapps.com/TextAreaProblems.mp4

The setup:

  1. The container control:

  2. The form with the grid canvas and the container control open:

The issues in the video:
1.
Issue: ScrollWheel does not work as expected
Action: I click in the Textarea to gain focus and use the ScrollWheel
Result: Textarea does not catch the MouseWheel, but the underlaying GridCanvas does
2.
Issue: Scrollbar does not work
Action: I try to move the ScrollBar of the TextArea
Result: Scrollbar is ignored and a text selection is done
3.
Issue: ScrollBar buttons do not work
Action: Clicking on the down and up buttons
Result: Down button works, up button is ignored
4.
Issue: Although being not-styled, able to insert non-styled objects
Action: Pasting a picture
Result: Picture is inserted into the textarea and should be ignored
5.
Not demonstrated in this video, but clicking on the ContainerControl is sometimes ignored and ‘bleeds through’ to the underlying canvas.

I think a lot of issues are because Xojo messes up the ZOrder of things. Also the ‘bleeding through’ of events is causing troubles.
Some program languages can solve this very elegantly:

  1. Check the mouse ZOrder from top to bottom
  2. If an event (like MouseDown) is ‘catched by a layer’ (could be just by declaring the event in Xojo), the event is not sent to the underlaying layers.

Related to 2: pressing the OK button (using the enter key in Action should stop there). Now it also raises the KeyDown event of the underlying canvas. As a hack, I have now a ‘switch’ that ignores it if it comes from Action.

A similar ‘Switch’ hack was needed for the shadow part of the container control, as the paint event was called twice, but only the first time the canvas was cleared. The result was a very fat shadow.

I apoligize if I sound annoyed, but this kind of stuff makes it very hard to build professional software with Xojo. I love it that we will get Raspberry Pi support, but a serious Windows cleanup cycle is absolutely needed. I’m not doing something weird here, this is very basic stuff any programmer expects from a programming language.

Note: I would’ve entered these issues in the feedback app, but it keeps crashing halfway entering the report.

I’m prepared to send my code to a Xojo Tech (as this a proof of concept my boss asked to show Xojo is the right tool). Last year I may have won the tough battle to stay with Xojo instead of .NET, but I have a feeling I’m finally losing the war. Give me some ammunition Xojo, I’m getting slaughtered here…

2

You might get better results if you put the popup TextArea in a Window (play around with the various window types and borders) rather than rely on the Container.

3

@Bob Keeney This is indeed the other idea I was playing with, but I would loose some ‘modern features’ like custom transparent shadows, irregular shaped popup controls (like a round clock) etc. I truly believe Xojo should be able to handle stuff like this. But I have a feeling I’m going to end up like I did many times before: 1 Canvas + 1 EditField and writing everyting else (like drawing combos, listboxes, date input boxes, ‘virtual windows’, drag/drop, tab cycling between virtual controls, etc) myself. In our company, the user experience is top priority e.g. a combo must behave (and have the look and feel) like it does when you use the Google search box in your browser. And I’m very close with that one.

I have done it before (1 Canvas, 1 Editfield, drawing everything else) with the current version of our tool. But for once, I would’ve liked to show to my boss it can be done the ‘normal’ way. If I have to solve it this time by writing everything myself, I loose.

P.S. Didn’t you used to have a custom TextArea control for sale? If so, does it handle these annoying issues?

4

I know MBS has some window overlay class that you might be able to simulate some of this functionality. I haven’t done it in any of our projects but I know some use it for just that purpose.

Nope. Not us. FTC is our only TextArea replacement.

5

Use a popup Window for the container window. You can do much with it. First of all, with custom Win32 declares you can make the window borderless, and not steal the focus from the main window. As for the shadow, you can track the container control’s position, and just paint it in the grid.

This way you won’t experience any “bugs” which are caused due to overlapping controls.

6

This is a good idea. Will need some calculations to remember wich cells are effected (the combo can grow/shrink) but that is all very doable. As for the declares, I’ll try to avoid them if possible as it would need to work on OSX also. But this could bring me closer to my goal :slight_smile:

7

On windows isn’t the ContainerControl a “Window”? All Windows controls are “Windows”…created using “CreateWindowEx” API. The only difference between a ‘Window’ Window and a Container Window/Button/Label/What-have-you, is the class-name which is applied to it. So the issue definitely is frame-work side. I’ve already started re-writing control sets for Windows and Mac to replace the Xojo ‘native controls’ (and bugs). The Mac RichTextBox is the native Mac RichTextField, with no ‘TextInputCanvas’ plugin hackery, and the Windows version uses the native RichTextBox (from richtext dll found on all windows systems) as well, and accepts images, and all native RichTextBox features. Currently, all that is needed is to combine the two OS versions and change the function names and properties to match cross-platform. The purpose of the open native control sets will allow developers access to the underlying issues, and make them easily fixable without having to file feature requests and wait for a new Xojo release, to hopefully see a fix. The problem with the ContainerControl is indeed that events sometimes reach the container, while other times the events reach the embedded controls, as you mentioned.

Here’s a demo of some of the native Windows controls (and a few natives that Xojo doesn’t offer:-)) (You’ll also notice that if controls do not have a specific size limited by the OS, they can be sized upto any scale, like the UpDown control, which in Xojo’s version limits to one size.) The controls use the Canvas class initially for placement and sizing within the Xojo IDE, but at runtime creation, the Canvas class is switched to the native control classes as specified by the APIs. The control sets will hopefully remove a huge growing issue (like mentioned in this post) seen among developers, and provide Native-Native replacements for the Xojo-based controls, in which developers will have control over the control code and quality.

Windows Demo Code & Controls:
http://www.xojodevspot.com/demos/native-controls.xojo_binary_project

I’ll see if I can’t finish up the RichTextField(Area) over the next 2-3 days. Would be interested to see if clears up the issue.

8

“textinputcanvas” hackery ? Unless you implement things as a plugin you won’t get platform correct behaviour for dictionary lookups, press & hold input to select one of many variants of a character (press & hold the e key when in the code editor on OS X and you’ll see what I mean) nor will you get proper handling of the various input methods as it requires several delegates & protocols.

Since there’s no “mac richtextfield” so I’m not sure what you’re implementing
It’s API on OS X it very different from “RichText” on Windows

Third - the project you posted crashes on launch on OS X

9

[quote=187012:@Norman Palardy]“textinputcanvas” hackery ? Unless you implement things as a plugin you won’t get platform correct behaviour for dictionary lookups, press & hold input to select one of many variants of a character (press & hold the e key when in the code editor on OS X and you’ll see what I mean) nor will you get proper handling of the various input methods as it requires several delegates & protocols.

Since there’s no “mac richtextfield” so I’m not sure what you’re implementing
It’s API on OS X it very different from “RichText” on Wdragindows

Third - the project you posted crashes on launch on OS X[/quote]

The project file given is windows only. The Mac version I’ll post. The Mac version creates and uses the native Xojo TextArea and uses declares from the Mac framework to extend the Xojo TextArea itself, also allowing it to interpret HTML as well as RTF with images embedded (for both). Indeed it has been a ginormous hassle, but a great exploration exercise. IMO Mac offers a truly more robust RTF experience over the windows platform. Plus developers will be able to use the code as reference to create and use other native OS controls for use within the friendly drag-and-drop Xojo IDE, not currently available. I’ve seen a growing rise in “this control is not available” or “I want native non canvas-based controls for such-and-such” (IMO they’re just as powerful). I don’t think some developers truly realize just how powerful Xojo actually is, or without particular direction in certain areas, quite where to begin. Seeing, is believing. As with the ListView, a developer was recently willing to start at square one, learning another language tossing Xojo out the Window, because it was falsely believed that the Windows ListView couldn’t be implemented without all the complexities of ActiveX or an OLEContainer; and used as any other Xojo control. The goal is to implement a set of native controls that developers can extend, bypass bugs incurred found in the framework, and learn how to implement native controls ‘the Xojo way.’ I could give them a ‘fish,’ and feed them for a day, or teach them to ‘fish,’ and they can eat for a lifetime.

10

Just FYI that if you’re using TextArea then you’re using TextInputCanvas and get all the input mechanism support from that
No “hackery” required :slight_smile:

11

[quote=187147:@Norman Palardy]Just FYI that if you’re using TextArea then you’re using TextInputCanvas and get all the input mechanism support from that
No “hackery” required :)[/quote]

Thank God! It’s horrendous to use from scratch :slight_smile:

12

Do you happen to have that Declare? This is something I need to do in a few spots in my application,

13

See Axel Schneider’s brilliant project you can download too, at https://forum.xojo.com/8264-any-way-to-insert-graphic-into-textarea?search=TextAreaDeclares

14

Thanks, Michel, I’ll check it out.

15

Sorry, Merv, I posted a link to a Mac rich text area declare. Not to a solution for a non focus floating window without border.

I have used the Windows example CustomWindowShape to remove the border, but it is a bit slow. I believe it should be easy to set the regions by coordinates instead of looking at every pixel and set the transparent areas this way, it would be a lot faster.

The core of the program is in the shapeform method, specifically these lines

r2 = CreateRectRgn(x, y, x2+1, y+1) i = CombineRgn(r1, r1, r2, 2) i = DeleteObject(r2)
If you set x, y, x2+1, y+1 to the borders to remove, there is no need for the double loop that goes through every pixel, and the window is much faster.

incidentally, the very same technique is used in Windows 10 to produce borderless windows.

As for a floating window that does not still the focus, kind of a palette, I am sorry to admit at this moment I do not know how to do that in Xojo.

I had saved a link to a rather long discussion on the topic but never found the time to experiment in Xojo.

16

Of course I can.

Download link

Works on Windows only and uses WFS code.

After you run it, click the show button, and then you will see a borderless window. The borderless window doesn’t get focus when you click on a canvas or a blank spot in the window. But it gets focus when you click the button (with some work that wouldn’t steal the focus too).

Very bad code, cause I was just doing some tests.

17

[quote=187308:@Ashot Khachatryan]Of course I can.

Download link

Works on Windows only and uses WFS code.

After you run it, click the show button, and then you will see a borderless window. The borderless window doesn’t get focus when you click on a canvas or a blank spot in the window. But it gets focus when you click the button (with some work that wouldn’t steal the focus too).

Very bad code, cause I was just doing some tests.[/quote]

Thank you Ashot. I was precisely looking at a way to build palettes.

18

Thank you Ashot, I will look at it this afternoon. Thank you very much.

19

Thanks everyone for your suggestions and thoughts on the problem(s)! I’m able to solve most of them in one way or another. I still think we have to do to much ‘hacking’ to get something like this working on Windows and there certainly is still some work on the TextArea control.

Some of the solutions you suggested I’ve used:

Issue: ScrollWheel does not work as expected
Solution: Moving it to another window using some APIs to remove borders and make topmost
Drawbacks: The grid is Windows only and the ‘BigTextControl’ window comes partially out of the parent window if resized by the user.
2, 3.
Issue: Scrollbar and buttons do not work
Solution: Removed the ‘shadow canvas’ from under the TextArea (Appeared to catch most of the events of the scrollbar). Used an extra canvas on top of the grid canvas for the shadow.
4.
Issue: Although being not-styled, able to insert non-styled objects
Solution: None yet

As for my combo, I still use it as a ContainerControl, as that works great. All problems appear to start with the TextArea control.