WebTextField alternative

After spending the morning trying to do something I expected would take an hour, I’m a little shocked by what I found.

Xojo 2020R2.1 It seems the WebTextField control doesn’t have a .pressed event and only raises .GotFocus and .LostFocus when the tab key is used.




Please someone tell me I am wrong.

If I am not wrong is there any work around, that does not rely on pouring more money in.

What I need to do is is show a table when the textField is entered.

What do you want to achieve ? By “entered”, you mean when a key is hit ?

You could use TextChanged.

Does that mean that you want to type something and show a table after your press enter/return?

GraffitiTextField supports GotFocus, LostFocus, has an EnterPressed event, and a whole lot more. If you’re looking for something more like a searchable popupmenu, GraffitiPopupMenu may be better suited to the task to reduce round trip messaging to show/hide the list based on events.

Thanks for the response.

To be clear about the requirement.

I want to display the table as soon as the textfield is clicked, without the user having to type tab, or enter, or anything at all.

@Anthony_G_Cyphers As far as I can see I would need to pay another $400 to use a GraffitiTextField. Rather a lot for a single core function one would expect to find in the box.

Yes, but in my experience once people get started down the GraffitiSuite path, they find much more that they want to incorporate. At any rate, sorry my recommendation wasn’t helpful. I hope you find what you need.

1 Like

If the TextField has no focus, then clicking the TextField will fire the TextField GotFocus event.

1 Like

That is what I would expect but it does not work like that in 2020R2.1 The WebTextField only fires the .GotFocus event when the tab key is used to shift focus.

This is a bug. You should try subsequent versions of Xojo.

A new version of Xojo Pro costing what, $800?

If it is a bug that has been fixed the fix should have been offered in a point release. There is a strong argument for the functionality being a reasonable expectation, without which the product or a large part of it is rendered unfit for purpose.

As I indicated I am absolutely stunned to find a textField that does not trigger gotFocus on a mouse click.

Have a look at the Web SDK. You can do whatever you want. A major goal of the Web 2.0 rewrite was to minimize the bandwidth between client and server. Out of the box, focus events don’t require a round trip from the browser to the server, which is a win for most projects. If you require that functionality, you can code it.

1 Like

+1 for websdk.
doing web 2.0 without websdk will force you to use very basic controls.
if you want fine controls you must learn to use and code your own websdk

graffiti is a whole bunch of websdk ready made for you. but it has a cost.
Anthony cannot work for peanuts…

your expectations in xojo are too high.

1 Like

My suggestion was simply to verify the bug was still around. Which you can do without buying a new license.

I am afraid you are embarking on a goose chase, here. Bug fixes come with every release (point and all), and are not retroactive.

Now, there is a way to get the focus event in JavaScript. This is the WebTextField Shown event:

Sub Shown() Handles Shown
  var js as String
  js = js + "document.getElementById('"+me.ControlID+"_field').setAttribute('onfocus','location.hash=""focus""');"
End Sub

When the focus event occurs, the hashtag becomes “focus”, and you get it in the Session.FocusChanged event:

Sub HashTagChanged(Name as String, Data as String) Handles HashTagChanged
  system.DebugLog Name
  If name = "focus" then
    // Do what you need for the focus event.
  End If
  HashTag = ""
End Sub

Hashtag = “” removes the “focus” hashtag, so the event fires next time.

Note that this is a quick workaround. If you want a more elaborate way to tap into the DOM, check WebSDK.


My bad. HashTagChanged.

@Matthew_Stevens you may want to have a look at the JavaScript workaround above.

No disrespect was intended. Verifying (for myself) that the bug is fixed in a later version wouldn’t be very useful because there is an $800 barrier to utilising the later version. At this point the project I am working on does not have a spare $800, around 10% of the milestone budget, to spend on development tools.

I am not going to be chasing any geese, thank you for your concern. Xojo can do as it likes and I can believe what I like. I don’t believe I need to prove pointer driven focus events are a fundamental concept and core requirement of event driven visual programming tools. I do not believe quoting terms and conditions generally excuses selling product of dubious merchantable quality and demanding customers cover the cost of rendering it useful. At this stage I am starting to believe committing any more to Xojo would be throwing good money after bad.

Thanks. I will give it a go when I am back in the office tomorrow and report back.

I would not start a project with xojo web 2.0 with a not-up-to-date version of xojo …


The requirement at this point is for very basic controls. I do not doubt that Graffiti Suite and MBS and Chillkat are all worth their cost in the right use case. I am not in those use cases.

My business provides network solutions that occasionally require narrow scope software development in the region of hours, days, weeks, a month or two at most. RAD tools have been a part of that business for over 25 years now. In the past I used Real Basic and Real Studio but stepped away at the transition to Xojo. I purchased a Xojo Pro license in 2020 to add TLS1.2 to some of our internal tools.

I am currently assessing whether Xojo Pro has any hope of paying for itself by leveraging a customer’s cloud integration project with a ‘meagre’ front end requirement. I have already done the heavy lifting with PHP. If I have to resort to the Xojo WebSDK I may as well go straight to java-script with the reams of free to use controls that comes with.

JavaScript for all its qualities does not have anything as user friendly as Xojo.

1 Like