Basic Windows Application Usage : Product lock up on lost dialog box

[PurdueEEGrad]

I can lock up the beta product - as follows;

[1] Launch the editor (the beta)

[2] Menu -> Macro -> Load Module (STOP)

[3] On Windows : Switch to UI to another program - like Windows Explorer

[4] On Windows : Swtich back to the editor (the beta)

[5] Product locks up

On [2] you leave the dialog box alone - do not navigate or select any module to load.

On [4] the editor comes back - but the Load Module dialog is 'lost'.

Since its single thread - you can not get back to the product - even to exit.

You have to use an OS task manager - to kill the product to exit it.

The customer use case is - go to load a module - then get the target directory
via a copy of the target path - via Windows Explorer. When you go to enter
the path - the dialog box is lost - and the product is locked up.

[Clark]

What version of Windows are you using?

[PurdueEEGrad]

SlickEdit 2014 (v19.0.0.8 64-bit)

Serial number: FE20965_BETA
License type: Beta License
License expiration: 2014-11-06 07:47:00
License file: C:\ProgramData\slickedit\19\slickedit.lic

Build Date: September 16, 2014
Emulation: CUA

OS: Windows 7 x64
OS Version: 6.01.7601  Service Pack 1
Memory: 45% Load, 3763MB/8190MB Physical, 4256MB/16378MB Page File, 362MB/8388607MB Virtual
Shell Info: C:\Windows\system32\cmd.exe /q
Screen Size: 2048 x 1152

Project Type: Other
Language: .txt (Plain Text)

Installation Directory: C:\Program Files\SlickEditV19.0.0 x64 Beta5\ (non-removable drive,NTFS,103212MB free)
Configuration Directory: C:\Users\John\Documents\My SlickEdit Config\19.0.0\ (non-removable drive,NTFS,103212MB free)

[Clark]

I can't reproduce this. For me, the Load Module dialog stays visible and on-top of the editor no matter what I do. Windows is usually pretty reliable with this sort of issue. Usually we see this sort of issue on Unix/Mac but on those systems you can typically bring the dialog back to the top.

[Rodney]

This sounds like a problem others have worked around by deleting their workspace tag file before starting the editor.

++rodney

[PurdueEEGrad]

This is not a major problem for me - once I know about it. Though it should be logged
in, however, just in case its related to other kinds of dialog lockup - reported by others.
I will retest in the next beta release - on a virgin install (ie; no prexisting config directory).

[PurdueEEGrad]

I retested this - and the lockup works under the following conditions.

[1] Bad : Launch Slickedit - no workspace loaded - immediately try to load module (bring up dialog).

[1.a] Switch to another application - then reenter Sickedit - dialog is NOT there.

[2] Good : Launch Slickedit - open a workspace - immediately try to load module (bring up dialog).

[1.a] Switch to another application - then reenter Sickedit - dialog IS there.

The lockup seems repeatable (on my system) - when no workspace is open. So if you try to load a
module - without a workspace open - then the lockup occurs.

If I open a workspace (and load a module) - then close workspace - the lockup is
still repeatable (ie; with no workspace opened - after closing a workspace).

When I first install Slickedit - on a virgin install (no pre-existing config directory) - I load my
configuration via modules (ie; Menu -> Macros -> Load Module).

If this is not repeatable on other systems - I can live with it (since I just
have to have a workspace open).

[Clark]

I still can't reproduce this.

[PurdueEEGrad]

I have put all my settings in a *.e file - and will test this on a virgin install.

There are some other things I need to test - so they can be repeated on your end.

After testing - I will post the results. Hope to be done later today.

The posting - if still a problem - will have the *.e file - that sets my options - for
the issue to occur (ie; on a virgin install). Finally I will test this right after the
virgin install - to see if the behavior is just my system - and not the options settings.

[PurdueEEGrad]

Still locks up on a virgin install. Note that;

[1] Other dialogs - such as Menu : Tools -> Options - does not have this problem.

[2] Make sure your Slickedit application is maximized under Windows - so it takes up all the real estate on the screen -
except for the tool bar. - (ie; Bring up SE - Expand to full size - pop the Load Macro dialog - then switch to another app).

[3] Switch to another app - like Windows explorer that is also maximized to use the entire screen (ie; DOS shell, browser, etc).

[4] Switch back to SE - using the application toolbar button - on Windows task bar at bottom of screen.

If, as in this test, SE is maximized - but does NOT push the Load Macro dialog box to the front. Then the application is essentially locked up (at least on my system it is).

I have SE 2004 V09 - and the Load Macro dialog box - comes up in the above test scenario. I get the same bad behavior in
SE 2013 V18 (product lock up). Also, in V18 - V19 : If you size the SE app window to less than the screen size - pop the Load Macro dialog - and move it towards the outside of the SE main window - and repeat the testing - you will find that the missing dialog appears.

In summary - when the Windows task bar button for SE app is used to switch back - the Load Macro dialog box stays behind the SE main window. No problem when the Load Macro dialog box is exposed in the real estate and the SE main window is over to one side - since you can select the Load Macro dialog box (because its visible). Its only when SE is maximized to take up all the screen estate - that the lock up occurs (because you can not get to the Load Macro dialog box which is behind
the maximized SE application window).

I'm fine with the problem (since its a nit once you figure it out) - but note that SE 2004 V09 - had the Load Macro dialog box
working correctly - where its displayed up front like the other dialog boxes (ie; Tools -> Options for example). Note, again, that on V19 the Tools -> Options dialog box works fine - and does not 'lock up' - and neither do some other SE dialogs I tested.

[4]

[Clark]

There's something else different about your system. If I perform the steps above, the Load Module dialog is always on top. I tried some other combinations as well with no problems.

[Clark]

Finally reproduced this. The work around seems to be to use Alt+Tab. This works even after the modal dialogs falls behind. I'm only able to get this to occur when SlickEdit has no open files. It doesn't seem to matter whether SlickEdit is maximized or not.

[Clark]

Fixed for next build after beta 6

[PurdueEEGrad]

I'll test it then. Also my system has tons of free tools and many software
developer tools. Many of the free software is from www.snapfiles.com.

A lot of the software has shell programs with various hooks, etc.

It would not surprise me if my system had some application that caught
a window message stream - and did not pass some messages down the line
(as it should). All the other high end developer tools are pretty solid -
most of them are from Microsoft, etc.