Window Focus (?) and Memory Leak

[megumi]

I have a stack which, when made into stand-alone applications, works fine under Mac OS X and Windows, but shows two problems under Linux (Xubuntu 9.10). One problem seems to be related to window focus issue and the other is a case of memory leak.

I am attaching a sample project file to demonstrate my two problems. It has one main stack 'Main' and one sub-stack 'Sub'. 'Main' stack acts as the application's main user interface, from which the user can open 'Sub' stack. ('Sub' stack is meant to serve as a user interface for data entry in my real project.) The stack script of 'Main' stack is inserted to the back of the message path on application launch, and most handlers are kept in it, including the most menu handlers.

What's meant to happen:
When the user opens the 'Sub' stack from 'Main' stack by menu command File > Open, 'Sub' stack opens in a 'locked' state. The idea is that the user can only enter/modify data in the 'unlocked' state, for which authentication is required. Edit > Unlock menu command will open a dialogue box, asking for a password. The preset password in this case is 'sample'. Giving it should change the state from 'locked' to 'unlocked', and the menu items under 'Edit' should change accordingly (enabling 'Lock' and disabling 'Unlock' menu items).

Problem 1:
After successful authentication, 'unlocking' does not take place, and the menu items under 'Edit' do not become enabled/disabled as they should. It seems to me that the problem is related to the fact that the window focus is lost from the 'Sub' stack (whose menu needs to be changed) when the dialogue box appears to ask for the password. I scripted so that holding down the shift key will bypass the password request, and the unlock menu-change works as intended. But after the password dialogue box appears once and causes the unlock to fail, all subsequent attempt for unlocking fails even with the shift-key held down. However, if I move the 'Sub' stack window by dragging its title bar, shift-unlock successfully changes the menu items as intended.

Problem 2:
After quitting the application, it remains in the memory as a process for each instance of application launch.

Curiously, neither of these two problems occur in either Mac OS X or Windows environment. They consistently occur in the Xubuntu 9.10 environment.

I am thinking that the problems are outside my Transcript coding, but related to some Linux 'features' or caused by some sort of bug in Revolution. I am using Revolution Enterprise 4.0.0.950. Please can someone help me solve these two issues specific to Linux? Thanks.

[Mark]

megumi,

Does it help, if you execute a go command or set the defaultStack property, to reset the focus, before continuing your script?

The process that continues running isn't really a memory leak. There may be several reasons for it, one being a bug that prevents Rev from quitting after the last window closes. This is a problem that may happen on Windows as well but can't happen on Mac OS X unless you write a script that doesn't pass the required messages.

The following might help: http://qurl.tk/7o

This script closes all components before finishing the Revolution standalone. You need to comment out the lines that you don't need (probably the lines connected to MySQL).

Best,

Mark

[megumi]

Dear Mark,

Thank you for your reply.

I tried executing 'go' (to stack "Sub") command and setting the defaultStack (to "Sub"), and I also tried the combination of "push card" and "pop card", but none of these helped to change the situation where the menu item manipulation does not take effect on the stack "Sub".

I also tried your script quitMyProject, but it didn't change the problem of the app staying in memory as a process on my Linux machine. I did not know whether this problem is rightly called 'memory leak', but it takes up chunks of memory which my old laptop does not have a lot of, and I want my app to release the memory on quit. I feel I ought to repeat that the problem happens only in a Linux environment. I tried the app on my colleague's Windows PC, and I confirmed in the task manager (?) that the app does not stay in the memory as a process after quit.

Any further insight/help would be appreciated.

Megumi

[megumi]

I contacted Runtime Revolution people about my two problems, and they quickly responded very helpfully.

Enabling/Disabling MenuItems of Menu Not Working on Linux After a Dialogue Box
This was confirmed as a bug and reported to RunRev Quality Control Center. <http://quality.runrev.com/qacenter/show_bug.cgi?id=8698> A workaround was given. Instead of 'enable (or disable) menuItem x of menu y', use 'enable (or disable) menuItem x of button y'. This works very nicely. I understand that Revolution implements menus as (groups of) buttons, but I think 'menuItem of menu' makes better sense than 'menuItem of button'. I hope they can fix the bug to make 'menuItem of menu' syntax work consistently on Linux as it does on Mac OS X and Windows.

Standalone App Staying in Memory as a Process
Runtime Revolution technical person wrote to me that the problem was not reproduced in his Linux environment, Mandriva and SUSE. However, the problem happens consistently in my Xubuntu 9.10 environment. Curiously, another standalone app I built using Revolution does not run into this problem, as it quits nicely in the same Xubuntu 9.10 environment. So, it looks like this issue is not a general Linux issue, but specific to Xubuntu.

Megumi

[FourthWorld]

I contacted Runtime Revolution people about my two problems, and they quickly responded very helpfully.

Enabling/Disabling MenuItems of Menu Not Working on Linux After a Dialogue Box
This was confirmed as a bug and reported to RunRev Quality Control Center. <http://quality.runrev.com/qacenter/show_bug.cgi?id=8698> A workaround was given. Instead of 'enable (or disable) menuItem x of menu y', use 'enable (or disable) menuItem x of button y'. This works very nicely. I understand that Revolution implements menus as (groups of) buttons, but I think 'menuItem of menu' makes better sense than 'menuItem of button'. I hope they can fix the bug to make 'menuItem of menu' syntax work consistently on Linux as it does on Mac OS X and Windows.i

Thanks for posting the link to the RQCC report, and the workaround. Very helpful info.

Standalone App Staying in Memory as a Process
Runtime Revolution technical person wrote to me that the problem was not reproduced in his Linux environment, Mandriva and SUSE. However, the problem happens consistently in my Xubuntu 9.10 environment. Curiously, another standalone app I built using Revolution does not run into this problem, as it quits nicely in the same Xubuntu 9.10 environment. So, it looks like this issue is not a general Linux issue, but specific to Xubuntu.

I'm doing an increasing amount of work with Ubuntu, and am using 9.10 on both my desktop and in my netbook (I use the Netbook Remix edition there), so I'll see what I can find on this one and report back.

Do you know if this one has been submitted to the RQCC yet?

Also: Do you have any timers or invisible stacks in use at the time you're quitting your app? Remember that pending timers will prevent the engine from quitting, and that quitting only happens when all stacks close.

[megumi]

Hello FourthWorld,

No, the issue about the app staying in memory has not been reported to RQCC, because the RunRev technical people have not been able to reproduce the problem in their Linux environment (Mandriva and SUSE), and thus not able to confirm it as a bug. The person who wrote to me said he would try the sample stack I submitted (also attached to my original post in this thread) on Xubuntu 9.10 to see if the problem presents itself.

I would be interested in knowing what you will find on your Ubuntu 9.10 machine. Please try my sample stack, compile it as a standalone for Linux and see if it quits cleanly. It's a very simple stack with no timer, no invisible stack, nothing complicated or pending. I cannot figure out why on earth it won't quit.

[FourthWorld]

I just made a build and ran it in Ubuntu 9.10: it showed in Processes while it was running, and after I selected File->Quit in your app it was no longer listed in Processes.

Do you have another computer you could test this on to see if there's something specific to your machine?

[megumi]

Dear Richard (FourthWorld),

Thank you for taking the time to try my stack and for your valuable feedback. I've just tested on another machine also running Xubuntu 9.10 as you suggested, and as you suspected, I found the problem NOT reproduced on that machine. I must therefore conclude that my problem is being caused by the way my laptop is setup.

I know this is no longer a Revolution question, but I would appreciate any help from anyone about what to do. I have no idea what to check or change. I am particularly puzzled as another (also very simple) app I made with Revolution works fine and quits cleanly on the same laptop.

Megumi

[FourthWorld]

I wish I could be of help with that, but I must admit I'm still very much a Linux newbie. Hopefully one of the more savvy Linux users will chime in on this, or you might consider posting a message to the use-revolution mailing list where a few very experienced Linux folks like Peter Alcibiades hang out:

http://lists.runrev.com/mailman/listinfo/use-revolution

That list is sometimes quite active, so I usually suggest folks sign up in digest mode at first.