Browse issue within application.com

[David Higgs]

Hi,

I have an application that's running fine within "Developer". The application has a "Pageframe" with a Tab that I use to Browse various Database files. When running the compiled .com program, if I try to browse any of the database files the program "locks up".
This same command works fine in "Developer"

I have the following in the "start.prg" file that calls the Menu page which in turn calls the "Pageframe"

SET SYSMENU OFF

IF WVISIBLE ('STANDARD')
RELEASE WINDOW 'STANDARD'
ENDIF



Regards,
David

 

[Mike Lewis]

David,

Could you be more explicit about how the program "locks up"? What exactly happens? And have you tried stepping through the program in the Debugger to see which command causes the locking up?

I can't see anything wrong with your RELEASE WINDOW code. In fact, I have almost the same code in all my programs (except that I use HIDE WINDOW rather than RELEASE WINDOW, and at the end of the run I do a SHOW WINDOW to bring the toolbar back).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Hi Mike,

Thank you for your reply.

The "Lock up" is just that, if I click on "Exit" or any other option, nothing happens, the program just freezes. I thought maybe the "Browse screen" was open but not visible and that the program was waiting for me to close the browse screen, so I pressed the "escape key" to close browse with no joy. The only way out was by closing the program in "Task Manager".

It may be worth mentioning that my "Menu Form" has ShowWindow = 2 (Top Level Form) and the Form that contains the "Pageframe" is set to ShowWindow = 1 (in Top Level Form).

The program runs fine in developer; is it possible to Debug a compiled program?

Regards,
David

 

[Tore Bleken]

Add a button, "Exit", and add Clear Events into the Click method.

 

[David Higgs]

My "Exit" button contains a "Clear Events" which works fine until I press the "Browse" button then I get the lock up.

Regards,
David

 

[Tore Bleken]

Then you have something else going on, since Clear Event should exit the program completely.

 

[Mike Lewis]

Clear Event should exit the program completely

Not necessarily. CLEAR EVENTS will take you to the line following READ EVENTS. It doesn't have to take you right out of the program.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

The issue would appear to be due to using "Browse"; all other options appear to work ok until a "Browse" option is selected. It makes no different as to which "Browse" option is selected, the program still freezes.

Regards,
David

 

[Mike Lewis]

David,

Can you show us the code that launches the Browse. And also the code in your Exit button.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

Show us the complete code that includes Read Events. This is important, since a Clear Event will close the form and continue after Read Events. Also, could it be that the Browse simply is shown outside the visible are on your screen?

BTW, try to avoid Browse in your program, a grid is much more flexible and easier to handle.

 

[Olaf Doschke]

A grid control should be used instead of a browse, that's right. But if you use DEFINEd WINDOWs and legacy code, then form controls are not helpful. A BROWSE does wait for it to close via its upper right close button or CTRL+F4 or ESC, if you do it IN some window you'll have a window in a window.

Bye, Olaf.

 

[Mike Lewis]

One other point: Is the form (the one that contains the pageframe) modal or modeless? That might be relevant in this case.

Also, you asked if it is possible to debug a compiled application. Yes, is is, provided you have Debug Info ticked in the Project Info dialogue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Usually an app that "works fine in developer but not standalone" has structural problems related to improper use of READ EVENTS (if it's used at all).

Introducing BROWSE, which is its own wait state, could further confuse what's actually happening. At the very least, you should BROWSE NOWAIT (and I'm guessing you also need to include some combination of WINDOW and IN WINDOW clauses). It would be SO much easier to just use a grid control, which participates in the event model with more grace.

If the app works in the IDE but not standalone, then the app is relying on something provided by the IDE that you are not providing in the app.

You haven't shown us enough to make a guess at what that might be.

 

[David Higgs]

I've added the "NOWAIT" option to several of my browse buttons. The result is that if I click on a "browse button" that has the "NOWAIT" option I still don't see the "Browse Window", however I am able to continue using the program. If however I click on a "browse button" without the "NOWAIT" option the program freezes. I will have to look into using the WINDOW commands and / or look at using a GRID in the form rather than browse.


Regards,
David

 

[Mike Lewis]

And the answer to my question (two posts ago) about the form being modal or modeless?

But you are right to consider using a grid in place of the browse. A grid is definitely the way to go in this case.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Then it's really as simple as the modal browse hindering further actions. I wonder how you browse without getting the close button.
To keep BROWSE NOWAIT alive it has to be done IN some window that is not released or hidden.

Bye, Olaf.

 

[David Higgs]

Mike, sorry I forgot to answer your question. The Form that contains the "pageframe" that launches the "Browse List" was Modeless, I did try making it model but it appeared to make no difference to my issue.

Regards,
David

 

[Olaf Doschke]

Modeless is good, modal is the bad state.

Bye, Olaf.

 

[Mike Lewis]

Well, thanks anyway for checking. It was just another thing to tick off the list.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Reams were written about the WINDOW and IN WINDOW clauses (which do very different things) and most of that tribal knowledge evaporated as soon as we got the grid control. It's really much easier to work with unless you have very specific needs that call for a browse. I don't think I've seen one of those very specific situations in a decade or so.