Windows build only runs as background app

[Tony Taylor]

If you are experiencing an issue please mention the full platform your issue applies to:
IDE: IntelliJ 13
Desktop OS  Windows 8.1 64

My windows build completes successfully. When I install and run application - It only shows up as a background process in task manager.

Please tell me what I need to deselect/select to have my application run in foreground again.

[Shai Almog]

Do you mean the Windows Desktop build or Windows Phone build?
Do you have other Windows Desktop Codename One apps installed?
Did you use the MSI or EXE installer?

[Tony Taylor]

I reinstalled IntelliJ and codenameone the problem seems to of corrected itself. I was using .exe.

[Shai Almog]

Great.
Does that happen with the MSI?
You can build the MSI by adding the build argument: desktop.windowsOutput=msi

[barr...@gmail.com]

My windows desktop (msi) builds worked as expected until I upgraded from intellij 13 to intellij 15 with the corresponding upgrade codenameone plugin upgrade to version 3.4.2.

I have rebuilt three times (twice today) and all are running as background processes when installing the msi file on a windows 8 laptop.

[Shai Almog]

As far as I know nothing changed in the build process but Steve said he ran into a similar issue a while back and will look into it after the weekend.

[barr...@gmail.com]

Just as an update:

Today I did a full uninstall of IntelliJ. I installed the latest build

IntelliJ IDEA 2016.1.3

Build #IC-145.1617, built on June 3, 2016

JRE: 1.8.0_77-b03 x86

JVM: Java HotSpot(TM) Server VM by Oracle Corporation

and downloaded the latest codenameone plugin 3.4.4

I received the same result after sending the windows desktop build. 

[Shai Almog]

Since the build happens on the server your IDE or plugin version have nothing to do with it.
The only thing that might trigger something is build hints. Notice that you can target an EXE by using the build hints instead of an msi.

[barr...@gmail.com]

I uninstalled the previous MSI version then I changed my "build hint" from MSI to EXE, built and downloaded about 15 minutes ago. I received the same result, although it did install to a different location, it stills runs as a background process. 

[Steve Hannah]

I had some ideas, but I wasn't able to reproduce this problem, so couldn't really follow them through.

Perhaps your app is throwing an exception that is causing the window to hide.  

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/f8f8a280-31d5-4ab9-a41c-260c977b2530%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Shai Almog]

Try running the project from command line using java -jar with your jar file name. It should be somewhere in the installation hierarchy.

[barr...@gmail.com]

Thank you for the command line option. I used it and uncovered that Steve was correct in the assumption that my app is throwing an error. I have added a few debug output statements to help me identify the exact line that is hanging. Let me give a few pre-qualifiers to the scenario.

 

1) my app uses a standard splash screen which runs some initialization and registration checks

2) these checks are inside the postSplash function and the splash screen is never displayed

3) During these checks I scan the installation device for available storage paths and test the write-ability of each, this does throw some javaIO errors which are caught and handled correctly by my code

4) at this point in the code I would expect the splash screen to be visible but for some reason it is not

5) i make use of a "loading" label object to show status messages to the user and the code now updates that object 

 

I suspected that my app would be hanging on the "loading" label object modification statement of:

 

statusMsg.setText("Opening Registration System..."); 

 

but strangely enough it makes it past that line to hang on the next line: 

 

Dialog.show("Device Registration", "We will need to perform registration before you can make use of this application.", "OK", null);

 

I can see how both these lines of code could be problematic when the app hasn't actually come into view yet, but I can't understand why the app hasn't come into view yet.

[Shai Almog]

Dialog is a blocking method so if you show it during initialization you are blocking the rest of the initialization. Wrap the call in a callSerially(...) which will postpone it to the next event dispatch thread loop.

[barr...@gmail.com]

I have tried your suggestion with no success. I attempted 2 different variations before coming back to this support forum. In the first variation I included the "showForm("register", null);" line inside the "call serially wrapper" and the code froze at the same spot. I waited for approximately 5 minutes just to be sure it wasn't just a slow loading app.

For the second variation (the code segment included below), I moved the "showForm("register", null);" line outside the "call serially wrapper". This time the code froze on the same line of code, but in a different sequence. This time the "beforeRegister(Form f)" function was called and completed before the serial wrapper executed and froze on the "Dialog.show("Device Registration", "We will need to perform registration before you can make use of this application.", "OK", null);" line.

I've also included the beforeRegister() function so you can see there is no blocking calls made there. The only errors I get are the handled "Try/Catch wrapped" JavaIO errors I mentioned before.

System.out.println("setting status message text...");

statusMsg.setText("Opening Registration System...");

Display.getInstance().callSerially(() -> {
    System.out.println("Showing registration needed dialog serially...");

    Dialog.show("Device Registration", "We will need to perform registration before you can make use of this application.", "OK", null);

});
System.out.println("Opening Registration System...");
showForm("register", null);

@Override
protected void beforeRegister(Form f) {
    System.out.println("preparing to show register form...");
    registerForm = f;
    TextArea header = (TextArea)findByName("HeaderText", registerForm);
    header.setText("Evans allows a single user to be responsible for multiple devices. You give each device a 'Device Alias' (Please note special characters and spaces are not allowed) that identifies it in your account audit trail.\n\nIf you are already a member you only need to complete your email address, password and device alias to have this device added to your account.\n\nNew users should please complete all the fields in the form below.");
    System.out.println("Register form ready to display...");
}

[Shai Almog]

FYI you can check the "include source" flag and download a netbeans project that you can use to debug. This will allow you to press pause on the debugger and see exactly where all the threads are stuck.

Dialogs won't work unless a form is shown first. I'm not really sure I understand the flow you need to make sure that the form is shown and completes showing before any dialog is shown.

[barr...@gmail.com]

Thank you for the feedback so far.

I have NetBeans 8.1 but have never used it to debug and app developed outside of it before. I will take some time to learn as you suggested.

to assist your understanding of my situation, my app is a custom eBook reader and the app downloads books from my site.

For now, I am attempting to remove all use of Dialogs from the splash screen by transforming them into normal containers being added and removed as needed from the main form container. hopefully, this will allow the splash form all the time necessary to be shown. If this doesn't work then I will have to focus on the handled JavaIO errors and the possibility that my app trying to write to the root of the drives immediately upon running is somehow triggering a negative effect and windows is deliberately blocking my app from fully loading. (Just saying that actually sounds feasible)

As for the flow, it is pretty simple:

1) a simple splash screen from named "splash" was designed in the UI Builder with an Infinite Progress and a label which read "Loading.... Please wait"

2) the first action of the "Splash" form's "Post Show" event is to check for writable storage locations by creating and deleting a file

3) the second action of the "Splash" form's "Post Show" event is to run a few tests, the first of which is validation of registration by the existence of a file which is created during registration process.

4) if this file is not found or cannot be authenticated, registration is required and the user is notified of such via a dialog which opens the "register" form upon clicking the "OK" button. Herein the failure happens.

The issue is that the "Post Show" event on the "splash" form object is being triggered before the form is actually shown and the resultant Dialogs are freezing. 

Finally; The issue of not showing Dialogs until after I have made sure that the form is showing. I am working under the assumption of that being the purpose of the "Post Show" event. I am not aware of a form.isShowing() method so should I try attaching an addShowListener() call to the form in the beforeSplash event and remove the postSplash event handler completely? My concern is if the event is being triggered (which we have already confirmed), wouldn't the listener also be triggered?

[Shai Almog]

Since you use the desktop builds I'm assuming you have a pro account. You can use the support email alias you got in the welcome message and I can probably answer faster thru there.

A form has an addShowListener which is triggered after the form is actually shown (and the transition is finished) so often this is a better place for logic than the post show.

Try using a modless dialog in this case so instead of using the static show method you would create a dialog object and show it with showModless() or a similar method. This would mean the dialog will not block and execution can proceed as usual.