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

[Seth]

and what about disconnecting/reconnecting as i said before ?

[PabloMack]

Seth- Having to tear my scene apart just to make a single value change and then having to remember how to put it back together is a disturbing thought to me. 

[Klas]

I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.

[gregsandor]

I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.

That works for me too.

[Kadri]

I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.

That works for me too.

For such a basic thing to do you have to use a workaround ?
The good and old users are so accustomed to the way TG2 is ; they sometimes can not see that it could-should be in another way !
It is not only you , Gregsandor. Here or in other software forums you can see most of the time the same arguments ...

[gregsandor]

I said earlier that I like the fact that the values update as I type.  The cost of a workaround is worth the functionality to me.  Beyond that I have a list of three dozen things that I'd rather Matt and Jo concern themselves with before considering changing this behavior.

Don't you people have art to make?  Go render something!  

[cyphyr]

...

Don't you people have art to make?  Go render something!  

LOLZ 

agreed:)

Richard

[Oshyan]

Nice to see such an important issue getting energetic debate. We will of course consider all input and do our best to implement the best solution. Right now I see it as a compromise between present behavior and that suggested by some. The important areas of focus are obviously the heavy calculations, especially the heightifeld operators.

A full "transaction"-based system would be extremely onerous in my opinion. Having a *dialog* to have to confirm every numerical input would quickly be quite frustrating. I do think that lose-focus or Enter should confirm, and Esc can cancel. But we have Undo for values you want to back out of, no need for some explicit confirmation or narrowing the ability to confirm to just a few approaches (e.g. Enter *only*).

Anyway, we'll make the best UI balance we can, as always.

- Oshyan

[PabloMack]

Oshyan- I agree with all you've said.  It's just those pesky little un-invited popups that force a change of focus and cause an entry in the middle of typing that I don't like.  I have to ask myself "Now what was I doing before that nasty little popup interrupted me?"  Even yesterday, I had Lightwave rendering something and it interrupted me (in mid key stroke) right in the middle of a Terragen test and LW yanked focus away from TG just to let me know it finished.  I don't know how LW reacted to my TG key strokes.  I wish it weren't possible for a program to force a change of focus but I guess we are stuck with it.  

As far as the transaction processing issue, I really am only talking about making a transaction at the single value level, not at the menu level.  I can see how that could be a lot more involved than the simple thing I had in mind which is pretty much what you just described.  

[shadowphile]

its nice to see that my point has been well debated and I don't want to contribute any more noise.  thanks for all the vigorous feedback.

One thought I did want to make clear is my assumption that field entry was handled at a fairly low level by a subroutine, probably as part of the framework used to build the interface, and rather than recoding for each control one would only need to change the default behavior (if not hard-wired)

Another anecdote...
I build complex engineering interfaces for R&D software that is heavily GUI oriented and controls HW as well as other real-time tasks, for use by others.  Despite my best efforts to train the users ("its basically a beta, please let me know if you don't like anything or have problems"), I find out later when confronted by a problem they will often just play with the controls until they get the desired response and never tell me about their workaround!  (I usually find out because their attempts at workarounds will crash something and THEN they go looking for me.)  They are more interested in moving forward, just like the veterans of TG, and I can understand that.  It's very frustrating for me though (at work) and I still don't have a good answer.

[Klas]

I said earlier that I like the fact that the values update as I type.

The cost of a workaround is worth the functionality to me.

Beyond that I have a list of three dozen things that I'd rather Matt and Jo concern themselves with before considering changing this behavior.

[Henry Blewer]

(I usually find out because their attempts at workarounds will crash something and THEN they go looking for me.)

Been there.

[PabloMack]

I am writing the value in another field, the shadername for example, then with cut & paste I insert it in the field where I need it.

Reading your most recent posts makes me think that you (and maybe gregsandor) still don't realize that there is a difference between the two distinct issues here.  I think we all want new values to have immediate effect when a new value is entered.  If the pre-render is taking too much of your CPU time on a render that is certain to have to start over, by all means, Pause it with the supplied button.  But single key strokes within numerical edit fields cannot be expected to reliably reflect the new value until the appropriate string of characters is properly composed.  Pressing the 'Enter' key is merely a way to tell the software "Hey, I am ready with the new number.  You can use it now."  If this were built into the library edit routine(s) that is(are) used to effect new values, you wouldn't have to hunt for some innocuous dummy field in which to do the edit just to later cut and paste it from (and then be left with putting the dummy field back to its original value).  There is no sense in having to do that.  With the "automatic temporary buffer" approach, I think that you would actually get what you are wanting (i.e. immediate effect on the pre-render and node network) along with everyone else.  

I think it is great that this thread is revealing user's work-arounds to this problem.  I loved reading shadowphile's personal story that was shared on the subject.  Thanks a bunch. 

[shadowphile]

Ok, I pick PabloMack for my team   

[jaf]

I really agree with what PabloMack just wrote.

If I add a Heightfield (generate) and go to the pixel or meter size fields and click to the far left of the digits and by mistake enter an "a". The preview restarts, and the heightfield disappears.  No error messages.  You look at the xml and will find it's set to zero for that field.  

Here's another example that causes a crash on my computer:
Load TG2 with the default scene and add a Heightfield (generate).  Select the Heightfiled generate and enable "Auto generate".  Now go to the "Feature steepness" slider and start moving it to the right.  I get a crash. I suspect what's happening is the program is trying to recalculate the changing value from the slider.   Wouldn't it be better for the program to only do the new calculation after a second or so of non-slider movement? The slider seems to work like individual key inputs, but the slider is much faster and the software can't keep up.