bb.donnay-software.com

How is the DCGETOPTIONS LOCKWINDOWTOOWNER supposed to work. Based on the documentation, when used for a modal, it should limit the ability of the modal to be dragged outside the owner, which would be the application windows. However, when I use it for a modal popup, I can drag it off the application dialog, to the extent of the screen.

I am considering its use and wondering whether it could stop some wierd application lockup problems. I encountered yesterday a user, who has dual monitors, that had our application appear to lockup. I have a popup that shows the window titles tied to the application desktop, DC_Arrayview(appdesktop()). It showed a confirmation window with the position of -32035,32920 and size of 230,181, which would be off the screen. It normally would be at 682,519 or some similar location depending on the postion of the application desktop.

Obviously, if the modal dialog is off the screen, you cannot click on the yes/no.

I have the suspicion that sometimes a modal dialog is getting behind a dialog and thus cannot be clicked on. I have seen it happen but cannot recreate what causes it. Any other thoughts on how to prevent this from happening. I have searched through my application for all modal dialogs to assure that they always use the SETAPPWINDOW clause, and verify that it works normally. But in certain instances, I have seen it happen.

Hi Cliff,

We have the same problem. Sometimes we have a customer who succeed to do the same. The application seems locked, but the reason of the lock is a modal window behind the dialogs.

Did you come up with any solution, or a way to bring the window to the top. We have had this situation, I think since 331 or maybe earlier. In our environment, it is more involved as 1-6 copies of our application are running on the workstation, one for each separate company the collectors are working on.

Glad that I am not alone. Now for a solution.

I don't know how to prevent a modal window getting lost behind the window of another application, however I think I can prevents problems caused by a window that is off the screen when using DC_AutoRestoreWindow(). I assume that is what is happening?

Hi Roger,

In my case the application is opened only once, and the modal dialog in on the screen, not off the screen.

Hi Roger,

After some testing I fount the following.
1. I open my application.
2. I open a menuoption which is started in a new thread., example customers: customerthread
3. I open another menuoption which is also started in a new thread, example invoices: invoicesthread
4. In the thread of the invoices, I search for product which is opened also in a new thread: productsthread

At that moment I have the following on the Windows taskbar at the bottom of my screen.


If the customer now selects the left windows, which is the invoicesthread , the system hangs. If the user selects the right window, the productsthread there is no problem.

I don't know why with the opening of the productsthread a new window appears. I think it is because it is opened from a button on a modal window, where the other threads are opened from the main application.

I hope this explanation is not too confusing.

I don't use the DC_AutoRestoreWindow() function. This one user had two monitors but the program was only showing on one monitor. Still working on getting information on lockups on single monitor computers. Always seems to happen when I am not in the office. In this case, the user had several windows open and pressed the main application upper right corner X which will cause a confirmation modal popup to appear. This was showing off screen or not visible. It did however respond to the Y keystroke.

I think it is because it is opened from a button on a modal window

That is interesting.
I will look into this.