number entry in TG, why is it 'real-time'?

[shadowphile]

In the rest of the (modern) world, a user normally indicates a typed-in number is ready by clicking outside the box, or hitting Enter.

TG (and I just discovered GeoControl as well) has real-time entry.  If I have something like an auto-generate switch enabled, this causes fun things like something....being....re...built...every...time...I...type...another...digit.   aaaaaargh!!!!!!!
Another fun example: select all the digits first then start typing.  If the first digit would be an invalid entry, instant choke!

I've gotten used to using a Graycode approach (only one digit changed at a time) to mediate my number entering in TG, but today I reported a bug in GeoControl that I only discovered BECAUSE of the same number-entry problem.  (and it took me quite a while to realize because once an invalid number was entered, it permanently broke the GC code until the exe was restarted)
That's when I got sick and typed up this lovely post.

Are we stuck with this?  GC and TG both have similar looking (dated) interfaces and I wonder if this is due to similar graphical widget/window libraries?  Delphi?

thanks

[Oshyan]

Well, in TG2's case it's just a UI quirk that needs fixing. I'll make sure it's in our bug DB and it'll get taken care of in a future release. I don't know about Geocontrol, but TG2 uses a custom UI library.

- Oshyan

[gregsandor]

Please don't change that.  It is very useful for testing as a render is going.

[latego]

GeoControl is developed using PowerBasic; it gives away this information because when there are errors, you are shown the filename and it ends with the ".pb" extension (and, if I remember well, this was also officially stated by Cajomi on his forum).

[jo]

Hi Greg,

Please don't change that.  It is very useful for testing as a render is going.

You are really asking for trouble by changing values during rendering. Although TG2 lets you do it, it's not really very safe and could lead to crashes. It might be safe to do with some params, but in general you shouldn't do it.

Regards,

Jo

[jo]

Hi,

First off, the realtime update behaviour is by design. Obviously there are some situations where it's inconvenient, and unless it's decided that a change to a lose focus/enter approach is decided upon then the bugs that need fixing are the situations where it causes problems, such as you describe. I personally think having to change focus or hit enter to have a value accepted is kind of retro, rather than modern.

GC and TG both have similar looking (dated) interfaces and I wonder if this is due to similar graphical widget/window libraries?  Delphi?

TG2 on Windows uses standard Windows controls. Where controls are custom drawn, mainly to get around poor behaviour in the standard controls, the controls are drawn using Windows theme functions to ensure they take on the standard OS appearance. So, basically, they look however the OS (or rather, your theme settings) wants them to look.

Regards,

Jo

[gregsandor]

Hi Greg,

Please don't change that.  It is very useful for testing as a render is going.

You are really asking for trouble by changing values during rendering. Although TG2 lets you do it, it's not really very safe and could lead to crashes. It might be safe to do with some params, but in general you shouldn't do it.

Regards,

Jo

I know, and it's worth the risk to me.  I almost never crash TG (except for memory limits) and in the cases where I test this way so far none.

[shadowphile]

I don't see the relevance of whether a control response is retro or not.  My keystrokes should not be interpreted as MY number until I say so.  There are numerous fields tied dynamically to the internal models and needlessly cycling the cpu with meaningless numbers before I'm done typing...well...that's just not right. 

(which reminds me, the other day I was giving a password to a coworker and he ran off after I had only said the first syllable... )

[Henry Blewer]

Jo, this is a little off subject. The only time I find the input of a number inconvenient is using the carve river operator for heightfields. A 'GO' button would be wonderful in this instance.

[PabloMack]

Please don't change that.  It is very useful for testing as a render is going.

I don't think you understand.  Say a setting is 23 and you want to edit it to 24.  You first delete the '3' and the program starts re-rendering the preview based on a value of 2 which is what you are left with.  Then you type the 4 to make it 24, restarting the render once again.  Alternatively, you could first type the 4 making it 234 and the render starts over using the value of 234.  You then delete the 3 to get the value you want which is 24.  This starts the render again.  

NO SOFTWARE SHOULD EVER WORK THAT WAY.  Editing a number is a transaction.  It is comitted or rolled back all-or-none.  You should edit the whole value and the new value isn't accepted as a transaction until you type Enter.  It is at this point that a pre-render should start over.  But press Escape, and the number should return to its original value with "no harm done".  If you have a pre-render in progress, it is not interrupted.  I can't see any use whatsoever in values being continuously taken as the new value as you are typing it.  A seeming exception to this is with searches when the software is implementing auto-complete.  But even in that case, it isn't actually submitting a search to the search engine with every key stroke.  It is only making suggestions for (guessing at) completing your query text.  Excellence can never be achieved by emulating a preponderance of badly implemented software.  

Thank you shadowphile for making thie very important observation.  

[dandelO]

Select the digit you want to replace on its own(highlight with the mouse, that is), then type. One refresh.
Not ideal for more than one digit but, I can see the benefits in both real-time edition and user dependant edition.

Grass clumps and erosion/river operators are the only real problem nodes for this, I think.
Everything else only refreshes the 3D preview/shader previews, which should, in my opinion, be paused between most keystrokes. Mine is paused more than it is rendering, anyway.

[PabloMack]

Select the digit you want to replace on its own(highlight with the mouse, that is), then type. One refresh.
Not ideal for more than one digit but, I can see the benefits in both real-time edition and user dependant edition.

This won't work going from 19 to 20 (like dandelO says).  With 19 in the field, you could go into notepad and type 20, select it and then Ctrl-C.  You then go into the field you want to change and select the 19, then press Ctrl-V.  It will work as a transaction.  But I think that if the TG2 staff found you were using notepad to work around the deficiencies of their software, they should feel like they haven't done the best job they could.  

[PabloMack]

I personally think having to change focus or hit enter to have a value accepted is kind of retro, rather than modern.

What would you think about a banking web interface that would submit a check for every digit you typed into (or deleted from) the "amount" field even in the 25th century?  Personally, I think changing focus shouldn't even cause accepting a value into a field.  It should leave what you are doing completely "on hold".   Coming back to it (giving focus back to it) should let you pick up exactly where you left off like nothing ever happened.  I hate it when I am in the middle of something and a stupid window pops up unwanted.  This causes the focus to change and, in badly designed software, it causes an entry to be completed that you didn't want.  VERY BAD IDEA.  A lot of modern technology is proof that things don't always get better.  They often get worse.  What it boils down to is that a lot of people get used to using badly implemented software and they get frustrated with well-designed software because they are not used to it.  It is a shame when well-designed softare is intentionally retro-graded to please the masses.  Disasters become more common place, but the ignorant masses don't ever seem to realize that they brought it on themselves (and everyone else).   

[cyphyr]

It it really that big a deal? It takes only a few tenth of a second to type a number compared to the several min the preview can take to finish loading.
The only similar issue I have found is that with complex networks, if they have been loaded for a while, there is a tendancy for the cursor to become ever so slightly "stuck" in a number input box. Pressing "enter" or "tab" or "clicking in the next box" dose not release it imeadiatly, it can take maybe half a sec to a seccond. Annoying but not serious.
Richard

[dandelO]

...Not ideal for more than one digit...

I did state that, as well. ^^

Really, though, how slow is your 3D preview rendering if you choose not to pause it between key-strokes?
I don't see why you wouldn't keep your previews paused, anyway. Like you say, what's the point in unwanted rendering and cpu usage?

Get into the habit of using the pause/unpause button, really.
Consider it your new 'refresh preview' button, instead of a constantly running process.