Keystrokes echo spaces in textboxes in lower view of large form.

[amatureo]

I have a large form that uses setviewport() to move between upper and lower views. Textboxes in the upper view work fine. Textboxes in the lower view don't echo the text that is typed in them. The text will appear once the control loses focus, but the user can't see it as they're typing. The cursor moves, but no text appears until they press ENTER or TAB.

There are textboxes in the middle of the form that show up in both views. These textboxes work correctly in the upper view, but the same textboxes have the 'non-echo' behavior when in the bottom view. Something is happening when setviewport() changes to the bottom view that alters the textbox entry behavior. It also occurs if the mouse is used on the slider bar to go to the lower view.

I've spent three days trying to figure this out.

Any suggestions?

 

[Olaf Doschke]

I've tried to reproduce, but can't. Can you post some code to reproduce, perhaps?

This form exported by "viewcode" from the class browser works both when scrolling down manual or via buttons viewport position:

DEFINE CLASS form1 AS form
	Height = 153
	Width = 329
	ScrollBars = 2

	ADD OBJECT text1 AS textbox WITH ;
		Height = 23, ;
		Left = 24, ;
		Top = 120, ;
		Width = 100, ;
		Name = "Text1"

	ADD OBJECT text2 AS textbox WITH ;
		Height = 23, ;
		Left = 24, ;
		Top = 24, ;
		Width = 100, ;
		Name = "Text2"

	ADD OBJECT text3 AS textbox WITH ;
		Height = 23, ;
		Left = 24, ;
		Top = 216, ;
		Width = 100, ;
		Name = "Text3"

	ADD OBJECT command1 AS commandbutton WITH ;
		Top = 24, ;
		Left = 168, ;
		Height = 27, ;
		Width = 84, ;
		Caption = "Command1", ;
		Name = "Command1"

	ADD OBJECT command2 AS commandbutton WITH ;
		Top = 216, ;
		Left = 168, ;
		Height = 27, ;
		Width = 84, ;
		Caption = "Command1", ;
		Name = "Command2"


	PROCEDURE command1.Click
		thisform.SetViewPort(20,300)
	ENDPROC


	PROCEDURE command2.Click
		thisform.SetViewPort(0,0)
	ENDPROC
ENDDEFINE

If you can provide a short sample form showing that behavior we might find a reason or workaround.

Bye, Olaf.

 

[amatureo]

I used form designer to create the form. It has a height of 629, 192 controls, and a LOT of code.

When the bottom control on the top view loses focus, LOSTFOCUS executes the following:

dodefault()

IF !MDOWN() AND !LASTKEY()=5 AND !LASTKEY()=19
thisform.SetViewPort( 0, 420)
thisform.txtdname.SetFocus() && Set focus on next control
ENDI

When the top control on the bottom view loses focus, LOSTFOCUS executes the following:

dodefault()

IF LASTKEY()=5 OR LASTKEY()=19
thisform.SetViewPort( 0, 0)
thisform.txtpDOB.SetFocus() && Set focus on previous control
ENDI

I have no idea why textbox entry changes depending on which view is active.

 

[Olaf Doschke]

I put in this Lostfocus event code into my first and last textbox and it still works without that negative effect.
Well, you could copy the form, delete all that doesn't matter. Use Viewcode and remove method code, that also doesn't matter.
If the behavior stops, you know it's caused by something you removed.

What I proposed a lot recently, when debugging doesn't help, is to record, what is executed, via SET COVERAGE. Do so at the Lostfocus of your txtpDOB: SET COVERAGE TO D:\coverage.log
Also put this into GotFocus of txtpDOB: SET COVERAGE TO. That stops coverage logging.

Now end Foxpro, restart the IDE and load the coverage log via Tools:Coverage Profiler. You'll see what code executes in between setting viewport to the lower view and back.

Maybe you'll find something that influences control values.

Other things to try: Turn off graphics hardware acceleration, or turn it on, if it's off. Update graphic driver.

Bye, Olaf.

 

[amatureo]

Your coverage log idea sounded superb. This is a copy of what was created.

0.006588,,registration.txtsmedical.lostfocus,2,c:\whil\forms\registration.sct,4
0.000053,txtdata,txtdata.lostfocus,1,c:\whil\libs\base.vct,5
0.000035,txtdata,txtdata.lostfocus,2,c:\whil\libs\base.vct,5
0.000027,txtdata,txtdata.lostfocus,5,c:\whil\libs\base.vct,5
0.000022,txtdata,txtdata.lostfocus,6,c:\whil\libs\base.vct,5
0.006098,txtdata,txtdata.lostfocus,9,c:\whil\libs\base.vct,5
0.000765,,registration.updateform,17,c:\whil\forms\registration.sct,6
0.000047,,registration.showhide,1,c:\whil\forms\registration.sct,7
0.000066,,registration.showhide,8,c:\whil\forms\registration.sct,7
0.000085,,registration.showhide,9,c:\whil\forms\registration.sct,7
0.000058,,registration.showhide,10,c:\whil\forms\registration.sct,7
0.000042,,registration.showhide,11,c:\whil\forms\registration.sct,7
0.000039,,registration.showhide,12,c:\whil\forms\registration.sct,7
0.000030,,registration.showhide,13,c:\whil\forms\registration.sct,7
0.000034,,registration.showhide,14,c:\whil\forms\registration.sct,7
0.000064,,registration.showhide,18,c:\whil\forms\registration.sct,7
0.000075,,registration.showhide,19,c:\whil\forms\registration.sct,7
0.000034,,registration.showhide,20,c:\whil\forms\registration.sct,7
0.005194,,registration.updateform,18,c:\whil\forms\registration.sct,6
0.000389,,registration.txtsmedical.lostfocus,3,c:\whil\forms\registration.sct,4
0.001531,,registration.txtsmedical.lostfocus,4,c:\whil\forms\registration.sct,4
,,registration.txtsmedical.lostfocus,5,c:\whil\forms\registration.sct,4
0.000049,txtdata,txtdata.valid,1,c:\whil\libs\base.vct,5
0.000057,,registration.txtdname.gotfocus,1,c:\whil\forms\registration.sct,5

I inserted a RETU at the beginning of SHOWHIDE, UPDATEFORM, and txtdata.valid to eliminate any influence, but it unfortunately didn't solve the problem. The middle textboxes are still not echoing the keystrokes in the bottom view. The same middle textboxes in the top view echo just fine.

Guess I have the unpleasant task of eliminating things until I can find the culprit, which will take a very very long time.

 

[Olaf Doschke]

Well, if COVERAGE didn't reveal it, you're unfortunate, unless someone has another idea. Hm, EVENTTRACKING would be another one. But, well, Coverage also covers code in events, event tracking would only reaveal events without any code in them, additional to the coverage log.

Your coverage log posted here does help nothing, without knowing the corresponding lines, Coverage profiler only shows them, if it has the files at hand. The shortness of the log shows, there is very little to inspect. Maybe look into base class code lostfocus in base.vcx, what these lines cause.

Bye, Olaf.

 

[amatureo]

I created a dummy form to test the situation.

Size of form the same as my original.

Four controls. One displaying in top view only. Two displaying in both views. One displaying in bottom only.

One middle control changes the view to bottom upon LOSTFOCUS. The other middle control changes the view to top upon LOSTFOCUS.

Yup. It works just fine without any textbox character echo problems in either view.

So something on my original form is causing the problem. The search is on.

 

[Olaf Doschke]

Good approach. That at least also shows it's not a computer hardware or config problem.
Good luck with the bug hunt!

One thing you could try is force event execution via DOEVENTS FORCE, eg in the textbox base interactivechange event.

Bye, Olaf.

 

[Dan Freeman]

Can I ask a question?

It has a height of 629, 192 controls, and a LOT of code.

192 controls? Really? REALLY? And you're trying to do this in a single pane rather than using pageframes?

Why?

 

[amatureo]

The 192 includes the labels as well as the textboxes.

It's a Patient Registration Form which contains one page worth of information.

I've used pageframes in other parts of my program, but because the Registration Form is replacing an old manual form, I thought it best to make it behave as a single page. Unfortunately, it isn't behaving!

 

[Dan Freeman]

Sounds like a bad idea to me. (And it seems like VFP agrees. )

(IMHO) The only time exact adherence to a paper form is acceptable is in an Acrobat document that you'll then print, sign, and mail, where an exact replica of the paper form is needed. (Most IRS forms are available this way.)

It seems to me your application should model the patient registration *process* rather than the patient registration *form*. I suspect your users will thank you.

 

[Olaf Doschke]

I agree with dan. At least in an application you have the chance to make it a process. If the paper form says "if ... go on with section..." you can often chaeck that programmatically and skip paper form sections, if they turn out to be irrelevant for that patient's registration.

But I look at another figure: Height 692. That urges the question: If there is a middle section you display both in upper and lower viewport setting, then the whole form would have a height lower than 1400 pixels, right? Doesn't it fit on the screen as a whole, then? What's the screen dimension? I'd expect at least (1920x)1080 or even (2560x)1280, today. At least the latter would leave enough space. If you work with two pages of a pageframe you'll make it without scrollable forms anyway.

On the technical problem of letters not showing, that has to do with some low level event not drawing font, only positioning the text cursor. If even DOEVENTS FORCE doesn't force the font letters to show, perhaps simply try a different font. That may simply be a font problem. I don't see how scrolled form canvas will change the rendering of the value displayed.

Bye, Olaf.

 

[amatureo]

The middle section shows on both views because there's only room to display 2/3 of the form at a time. The bottom half of the top view is the same as the top half of the bottom view.

I created the form using setviewport() so users could enter data without the need to grab the mouse and change pages. If I can't get my problem solved, I guess I'll end up with pageframes, and a ton of pgf.pg?? code modification busywork.

Not sure how the font could be the problem when the controls work fine in one view.

Will try the DOEVENTS FORCE.

Thanks for giving my issue some of your time.

 

[Olaf Doschke]

>Not sure how the font could be the problem.

Me too, but what else would cause blank graphics? It's true the problem can still be a foxpro issue showing with heavy loaded forms only. But even though 192 is a large number of controls from the user perspective, it's not a very large number of objects. If it's not a foxpro issue (which you could also test by deleting most of the 192 controls) it would need to be a gdiplus or os or font issue. Not necessarily an issue with the ttf font file, but with the font rendering. Kind of a last resort explanation. But changing the font is easy to do and if it works, it would be an easy fix.

Bye, Olaf.

 

[amatureo]

Okay, I guess I solved my problem without pageframes.

I inserted DOEVENTS FORCE in one of the controls interactivechange events and it initially appeared to solve my problem. But then I realized that I still needed the interactivechange event default code to fire, and when I put a DODEFAULT() into the control's event, my problem returned.

The interactivechange event default program is used to set a datachangespending flag which is then used by a handlebuttons method to enable or disable certain command buttons on the fly. Both top and bottom views of the form have command buttons for Save, but my handlebuttons method was enabling/disabling the top view Save button regardless of the viewport setting. I inserted code to enable/disable the bottom view Save button and that appears to have solved my problem. Not sure why, but if it works, I'll go with it.

Thanks for the suggestions that helped me navigate through my issue to a resolution!

 

[Olaf Doschke]

Causing visual changes to a form, like disabling/enabling buttons, draws away attention (Ha! Pun intended here), you might have caused suppression of the textbox event drawing the typed letter somehow, by introducing the need to care for visual changes elsewhere. In the end, it might have been a GDI+ resource problem and the pen or font resource was killed or reused by refreshing the off viewport buttons.

Well, good you found a reason. I would have guessed you already tried to suppress inherited code, as you said you did RETURN at the beginning of several events to eleminate their influence.

Bye, Olaf.

 

[Dan Freeman]

I created the form using setviewport() so users could enter data without the need to grab the mouse and change pages.

I just have to say this ....

Your users are no more required to "grab the mouse" to change pages than they are to call setviewport().

 

[amatureo]

You're absolutely right Dan. Careless comment on my part. Sorry.