# Open Windows Dynamically When Starting App **URL:** \ **Category:** Archived Topics\ **Created:** [February 27, 2008, 2:18am UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575 "2008-02-27T02:18:01Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![MickeyBob](https://avatars.discourse-cdn.com/v4/letter/m/e19adc/32.png) [@MickeyBob](https://forum.inductiveautomation.com/u/MickeyBob)\ **Post date:** [February 27, 2008, 2:18am UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/1 "2008-02-27T02:18:01Z")
Is there a way to dynamically specify what window(s) to open when the application starts? For example, I would like to be able to append a parameter, i.e., the window to open, to the launching URL and the parameter be available, say, in the application global script. ---
**Author:** ![nathan](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nathan](https://forum.inductiveautomation.com/u/nathan)\ **Post date:** [February 27, 2008, 6:54am UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/2 "2008-02-27T06:54:35Z")
I don’t think that you can pass/except parameters. Carl - is there some way of doing this? Retargeting does pass parameters with a similar mechanism, but I don’t think it’s open to you when opening a project. However, you can dynamically open windows with a Startup (Global) script. That allows you to base options on: OS, Hostname/IP, etc. Seems like a feature I’ve requested. It’s a good idea. ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [February 27, 2008, 4:25pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/3 "2008-02-27T16:25:47Z")
No, you can’t pass parameters through the URL to the client. The problem lies in how Java web start loads the JNLP file that prevents dynamic parameter passing. Sorry. You can create dummy projects that auto-login and then retarget to your project in various ways…not a perfect workaround, but it might help. ---
**Author:** ![Kyle\_Chase](https://avatars.discourse-cdn.com/v4/letter/k/9de0a6/32.png) [@Kyle\_Chase](https://forum.inductiveautomation.com/u/Kyle_Chase)\ **Post date:** [February 27, 2008, 4:47pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/4 "2008-02-27T16:47:09Z")
I dynamically open different windows on startup based off of the username or roles. I just went ```auto if user = "Me": fpmi.gui.openWindow("Awesome Window") if user != "Me": fpmi.gui.openWindow("Crappy Window") ``` ---
**Author:** ![MickeyBob](https://avatars.discourse-cdn.com/v4/letter/m/e19adc/32.png) [@MickeyBob](https://forum.inductiveautomation.com/u/MickeyBob)\ **Post date:** [February 28, 2008, 2:18am UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/5 "2008-02-28T02:18:51Z")
Kyle, [quote]I dynamically open different windows on startup based off of the username or roles. I just went Code: if user = "Me": fpmi.gui.openWindow("Awesome Window") if user != "Me": fpmi.gui.openWindow("Crappy Window") [/quote] Unfortunately, I don't think using userids/roles would work in my application because we have a very loose security model and I want to load specific windows based on the locations from which the users invoke FPMI. Carl, > [@](#): > > No, you can't pass parameters through the URL to the client. The problem lies in how Java web start loads the JNLP file that prevents dynamic parameter passing. I was looking at [http://www.cs.princeton.edu/introcs/85application/jar/webstart.html](http://www.cs.princeton.edu/introcs/85application/jar/webstart.html) and on this page they describe how to specify parameters in the jlnp file. Granted, I have a very limited understanding of how this works but couldn't it be possible to dynamically generate a jlnp file on the gateway from the URL parameters and then launch the application with it? If so, then the only thing missing is a way to access the parameters from within FPMI. Am I really out in left-field here? MickeyBob ---
**Author:** ![nathan](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nathan](https://forum.inductiveautomation.com/u/nathan)\ **Post date:** [February 28, 2008, 8:49am UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/6 "2008-02-28T08:49:26Z")
I don’t think we want to mess around with custom .JNLP files. Why not deal with location based on IP address or hostname? Storing your list in the database allows you to centrally manage access. There’s a similar example post [here](http://www.inductiveautomation.com/forum/viewtopic.php?t=2512). `myName = fpmi.net.getHostName() myIP = fpmi.net.getIpAddress() allowedHosts = fpmi.db.runQuery("SELECT hostName, IP, windows FROM hostList") for host in allowedHosts: if host['hostName'] == myName or host[1] == myIP: DO_SOMETHING` ---
**Author:** ![Robert.McKenzie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/robert.mckenzie/32/4134_2.png) [@Robert.McKenzie](https://forum.inductiveautomation.com/u/Robert.McKenzie)\ **Post date:** [February 28, 2008, 4:38pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/7 "2008-02-28T16:38:27Z")
MickeyBob, Does the system you are using to select the FactoryPMI page allow writes to the database? If so, you could use the database to your advantage. For example, you could have a table in the DB with a startup\_window\_name that is set before you open the FactoryPMI project. In the project, on startup, you could check that table and open the appropriate window, then reset startup\_window\_name to ‘’ (so the next time it starts, it would default to the main page). [code]#check what name you put into the db windowName = fpmi.db.runScalarQuery(“SELECT startup\_window\_name FROM startup\_window\_table”) #open the proper window (or the default if the empty string is there) if windowName == ‘’: fpmi.gui.openWindow(“Main Window”) else: fpmi.gui.openWindow(windowName) #reset the table to the empty string fpmi.db.runUpdateQuery("UPDATE startup\_window\_table SET startup\_window\_name = ‘’ ") [/code] Now, assuming people aren’t constantly opening projects, this should work out well. ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [February 28, 2008, 5:55pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/8 "2008-02-28T17:55:06Z")
> [@MickeyBob](#): > > I was looking at [http://www.cs.princeton.edu/introcs/85application/jar/webstart.html](http://www.cs.princeton.edu/introcs/85application/jar/webstart.html) and on this page they describe how to specify parameters in the jlnp file. Granted, I have a very limited understanding of how this works but couldn't it be possible to dynamically generate a jlnp file on the gateway from the URL parameters and then launch the application with it? If so, then the only thing missing is a way to access the parameters from within FPMI. Am I really out in left-field here? Our 'jnlp' files are dynamically generated. When you go to host:port/gateway/launch/projectname.jnlp, it dynamically generates an appropriate jnlp file for projectname. Now, you want to do this: [host:port/gateway/launch/project ... indow2=xyz](http://host:port/gateway/launch/projectname.jnlp?window1=abc&window2=xyz) And then have the dynamically generated jnlp file take those URL arguments and code them up as params in the jnlp file. Sounds good, huh? The only problem is that one of the first pieces of info in the jnlp file is the url of the jnlp file itself. This is so that JWS can go and look at the most recent version of the JNLP file when the app is launched from a desktop shortcut. And the kicker is that that URL in the jnlp can't have args due to the way JWS stores the url on the hard drive. (I tried this a year or so ago - no dice). Sorry for getting so technical, but you left me no choice 😉 ---
**Author:** ![MickeyBob](https://avatars.discourse-cdn.com/v4/letter/m/e19adc/32.png) [@MickeyBob](https://forum.inductiveautomation.com/u/MickeyBob)\ **Post date:** [February 29, 2008, 1:14pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/9 "2008-02-29T13:14:39Z")
Carl, > [@](#): > > Sorry for getting so technical, but you left me no choice Sorry for leaving you no choice.😆 It's interesting though. Robert, > [@](#): > > For example, you could have a table in the DB with a startup\_window\_name that is set before you open the FactoryPMI project. In the project, on startup, you could check that table and open the appropriate window, then reset startup\_window\_name to '' (so the next time it starts, it would default to the main page). I was actually working in this direction. I'll have to do a variation of this approach since FPMI can be launched on/from multiple workstations "simultaneously". I'll probably just add an additional column to the table to hold the workstation name and update the startup\_window\_name just for the row with the appropriate workstation name. Then in the global startup script, I'll get the local workstation name for use in my query (e.g., select startup\_window\_name from start\_up\_windows\_table where workstation = 'workstation\_name'). If there is no corresponding record, then I'll just startup with the default windows. ---
**Author:** ![Robert.McKenzie](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/robert.mckenzie/32/4134_2.png) [@Robert.McKenzie](https://forum.inductiveautomation.com/u/Robert.McKenzie)\ **Post date:** [February 29, 2008, 5:27pm UTC](https://forum.inductiveautomation.com/t/open-windows-dynamically-when-starting-app/575/10 "2008-02-29T17:27:03Z")
That sounds great. 🙂 I love that there’s always a workaround!