Display of Field Updates on Form

[Bill Desjardin]

To All,

I am seeing a strange situation re display of field updates on a form  
opened by a MODIFY RECORD command.  I have some buttons on the form,  
that when clicked, update the values stored in some fields of the  
record.  Some of the fields immediately display the updated values on  
the form, but others do not.  I have some fields that always show the  
updates, some fields never show the updates and some that show the  
updates some of the time.  These results are on Mac OS 10.4.11 using  
4D 2004.6r2.  If I switch to Windows 2000 or XP, the display results  
that show sometimes on Mac do not display at all.  I have tried all  
of the trickery that I can think of without being able to obtain  
reliable results.  Any ideas?

Bill Desjardin
**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[Paul Mohammadi]

Bill,

I curse 4D's ability or rather inability to update form elements on a
daily basis... sometimes they work flawlessly, sometimes they choke.
REDRAW command is pathetically ineffective.

The one sure fire way I found out that the form elements are drawn
correctly is by resizing the window by 1 pixel... Create your own
wrapper REDRAW_FORM where the form window is re-sized 1 pixel and then
immediately re-sized back 1 pixel, this way the original window XY is
maintained and everything on the form is updated... drawbacks are...
output windows and subforms need to re-page their data from the server
creating needless I/O but otherwise It should work.


Best

Paul
**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[MIYAKO]

Hello.

REDRAW and REDRAW WINDOW are no longer relevant and have no practical  
effect.
CALL PROCESS(-1), or RESIZE FORM WINDOW(0;0), as you have rightly  
pointed out,
is the current way to redraw.

to be more specific, you need to fire a form method, which both of the  
above effectively does.

the real question is, why would you need to redraw outside the context  
of a form event?

an understandable situation would be, that you have updated the values  
within a plugin.
in such cases you may execute Variable:=Variable just to notify 4D  
which Variable requires a redraw.

I have no definite explanation for the case Bill is seeing,
(obviously an On Clicked event has been fired),
perhaps it has to do with the layout order (level) of each objects on  
the form
and the manner in which 4D draws individual objects (from back to  
front).

maybe only Variables are subject to such immediate updates
whereas records require LOAD RECORD.

miyako

On 2008/05/16, at 3:57, Paul Mohammadi wrote:

> Bill,
>
> I curse 4D's ability or rather inability to update form elements on a
> daily basis... sometimes they work flawlessly, sometimes they choke.
> REDRAW command is pathetically ineffective.
>
> The one sure fire way I found out that the form elements are drawn
> correctly is by resizing the window by 1 pixel... Create your own
> wrapper REDRAW_FORM where the form window is re-sized 1 pixel and then
> immediately re-sized back 1 pixel, this way the original window XY is
> maintained and everything on the form is updated... drawbacks are...
> output windows and subforms need to re-page their data from the server
> creating needless I/O but otherwise It should work.

**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[Bill Desjardin]

Paul & Miyako,

Thanks for your input.  I tried the resize form ideas without any  
results.  The only way I could
get the fool thing to work was to do a SAVE RECORD & LOAD RECORD  
combo.  Luckily, I
am inside of a transaction and can roll back the changes later, if  
needed.

Bill

On May 15, 2008, at 12:33 PM, MIYAKO wrote:

> Hello.
>
> REDRAW and REDRAW WINDOW are no longer relevant and have no  
> practical effect.
> CALL PROCESS(-1), or RESIZE FORM WINDOW(0;0), as you have rightly  
> pointed out,
> is the current way to redraw.
>
> to be more specific, you need to fire a form method, which both of  
> the above effectively does.
>
> the real question is, why would you need to redraw outside the  
> context of a form event?
>
> an understandable situation would be, that you have updated the  
> values within a plugin.
> in such cases you may execute Variable:=Variable just to notify 4D  
> which Variable requires a redraw.
>
> I have no definite explanation for the case Bill is seeing,
> (obviously an On Clicked event has been fired),
> perhaps it has to do with the layout order (level) of each objects  
> on the form
> and the manner in which 4D draws individual objects (from back to  
> front).
>
> maybe only Variables are subject to such immediate updates
> whereas records require LOAD RECORD.
>
> miyako
>
> On 2008/05/16, at 3:57, Paul Mohammadi wrote:
>
>> Bill,
>>
>> I curse 4D's ability or rather inability to update form elements on a
>> daily basis... sometimes they work flawlessly, sometimes they choke.
>> REDRAW command is pathetically ineffective.
>>
>> The one sure fire way I found out that the form elements are drawn
>> correctly is by resizing the window by 1 pixel... Create your own
>> wrapper REDRAW_FORM where the form window is re-sized 1 pixel and  
>> then
>> immediately re-sized back 1 pixel, this way the original window XY is
>> maintained and everything on the form is updated... drawbacks are...
>> output windows and subforms need to re-page their data from the  
>> server
>> creating needless I/O but otherwise It should work.
>
>> On May 15, 2008, at 11:22 AM, Bill Desjardin wrote:
>>> To All,
>>>
>>> I am seeing a strange situation re display of field updates on a  
>>> form opened by a MODIFY RECORD command.  I have some buttons on  
>>> the form, that when clicked, update the values stored in some  
>>> fields of the record.  Some of the fields immediately display the  
>>> updated values on the form, but others do not.  I have some  
>>> fields that always show the updates, some fields never show the  
>>> updates and some that show the updates some of the time.  These  
>>> results are on Mac OS 10.4.11 using 4D 2004.6r2.  If I switch to  
>>> Windows 2000 or XP, the display results that show sometimes on  
>>> Mac do not display at all.  I have tried all of the trickery that  
>>> I can think of without being able to obtain reliable results.  
>>> Any ideas?
>>>
>>> Bill Desjardin
>>>

**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[Mehboob Alam]

Just looking for the "usual suspects" pointers.. I'm
working with an old v2003.6 structure on WinXP.

1) Is there any harm with opening it with an more recent
version of 4D, i.e. v2003.8r7 (?) and deploying back to an
environment consisting of v2003.6 client-server users?

2) Insider keeps crashing after I enter the designer
password.. it parses about partway and then crashes.

Any suggestions? Thanks in advance..


sincerely,
mehboob alam

"My interest is in the future because I am going to spend the rest of my life there." - Charles Kettering
**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[Arnaud de Montard]

Le 16 mai 08 à 05:02, Mehboob Alam a écrit :

> 1) Is there any harm with opening it with an more recent
> version of 4D, i.e. v2003.8r7 (?) and deploying back to an
> environment consisting of v2003.6 client-server users?

Opening with a more recent version is not a problem, but I've had one  
bad experience in 6.7.x doing "retro version deployment" (designed and  
compiled 6.7.2, deployed 6.7.1). At least, you should try.

> 2) Insider keeps crashing after I enter the designer
> password.. it parses about partway and then crashes.

sounds like a damaged object in structure. Have you tried 4D tools, or  
SanityCheck?

--
Arnaud de Montard





**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************

[Paul Mohammadi]

Miyako

>>> REDRAW and REDRAW WINDOW are no longer relevant and have no practical effect.

I am not sure this is a good statement to make as there are other
legitimate uses for using the commands. (at least for 2004)

http://www.4d.com/4ddoc2004/CMU/CMU00174.HTM

REDRAW command must be made to work as advertised.  It would be silly
to refresh a page with 3 subforms if only one needs to be updated.
Especially if the subforms are enterable!

REDRAW WINDOW can easily be considered obsolete but that is a huge mistake.

http://www.4d.com/4ddoc2004/CMU/CMU00456.HTM, it's easy to deduce that
the documentation's claim is a farce.  Most of the time when you need
to force the window refresh is because 4D doesn't update the object's
state.  Maybe 4D should have had a command like REDRAW OBJECT and make
it do what the documentation claims it does. This would also make the
idea of creating new commands like REDRAW LIST obsolete every time a
new feature was added.

In any case, 4D should move commands it deems as obsolete in to an
obsolete pile instead of sending developers scratching their head why
things don't work per documentation's claim :-)
**********************************************************************
The 4D v11 SQL Roadshow - coming to a city near you!
http://www.4D.com/roadshow/index.html

4th Dimension Internet Users Group (4D iNUG)
FAQ:  http://www.4d.com/support/faqnug.html
Archive:  http://dir.gmane.org/gmane.comp.lang.inug-4d.tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
Post: mailto:4d_tech@...
Options: https://lists.4d.com/mailman/listinfo/4d_tech
**********************************************************************