FiveTech Software tech support forums

I've observed a strange behavior when using dual monitors. When running the application on the 2nd monitor ( not primary ), when saving a numeric value, for some reson the value reverts to 0. If I drag the application back to the primary monitor, it works fine and saves the adjusted value.

I don't expect a solution to this problem, but rather I'm wondering if anyone has seen articles, or threads, on dual monitors that might relate to a program behaving differently on a second monitor than it does ( correctly ) on the primary monitor.

This is not specific to this location. I have a client who has observed the problem on all of their dual monitor workstations.

Tim,

> when saving a numeric value, for some reson the value reverts to 0

Are you using a dialogbox to get the numeric value ?

Do you show any MsgInfo() or similar before saving its value ?

Good Afternoon ( evening there ) ...

Actually, I am using a MsgInfo( ) ... and the data is stored in a dialog box. Its in a part system, and we notify the user when the quantity is 0.

Tim

Tim,

Please try it without the MsgInfo(), thanks

The problem occurs when I call MsgAlert within a VALID clause. Essentially, if the quantity available is 0.00, and the quantity 1 is entered, a warning shows about no stocking quantity ( MsgAlert() ) and then normally allows the Save of the actual entered quantity ( on monitor 1 ), but on the secondary monitor, it reverts the quantity to 0.

Tim,

Could you post a screenshot of both monitors screens at that moment ? Thanks!

The application is moved to the second monitor. During testing there is nothing on the primary monitor. I'm not splitting the application or moving dialogs. Everything operates on the 2nd monitor ...

Tim,

Is the MsgAlert() shown on the second monitor too ?

Yes it is. If I pull the window to monitor 1 it works perfectly. If I pull it to monitor 2, dialogs and messages line up the same, but when a MsgAlert displays, and then I try to save the record, the data reverts to 0. Its very strange.

Tim,

Anyhow, would you mind to send me or post here a screenshot of the second monitor when you save the data ? thanks,

Tim,

Are you using a dialog over a browse and if so, are you using a database object with the browse? I ask because if you are editing the database object buffer in the dialog and the browse gets repainted, the browse object buffer gets updated from the disk data. You have to either turn off buffering or use a TRecord object (part of TData for those of you who don't know). The msgAlert may be causing a repaint of the browse.

I don't know why this would only happen on the second monitor.

Can you repeat this problem with a simple dialog containg one get with numeric data all created from code?

James

James,

I think Antonio has an idea of what is going on because he asked me about the Msgxxxx( ) function.

It is rather strange. The behavior is excellent otherwise. This is found in adding parts to an invoice. Essentially, a blank record is added. The default quantity is 0. When the part is applied, all the data populates. Then I set the sold quantity to 1 . If there are none in stock, a message alert pops up and tells me that there are none in stock, but I can still add the desired quantity to the invoice. So the quantity 1 stays in place, but when I press the Save button to write the data to the physical record ( yes, I'm using tData ), it reverts the quantity to 0.

This only occurs if I have the open application on the 2nd monitor. If it is on the 1st monitor, no problem.

Tim,

>So the quantity 1 stays in place, but when I press the Save button to write the data to the physical record ( yes, I'm using tData ), it reverts the quantity to 0.

Like I said, if you are using TData directly (without turning off the buffer) and there is a browse, then when the screen refreshes, the data in TData's buffer will be reloaded from the disk. Despite seeing the 1 on the screen the buffer actually contains 0.

>I think Antonio has an idea of what is going on because he asked me about the Msgxxxx( ) function.

Any message or other app being brought to the top will cause the browse to be refreshed when it is redisplayed.

Try opening another program over the dialog, then closing or minimizing it. You will propably see the same problem.

Also try oDBF:lBuffer:=.f. before activating the dialog, then oDBF:lBuffer:=.t. just before saving or canceling the dialog. The problem will probably go away.

See also TRecord.txt in the TData files for an explaination and another solution.

James