How can we configure the install4j executable to take query parameters provided in the custom uri to take as arguments to pass to the main app - install4j

We have defined custom uri scheme for our Mac OS X using install4j but couldn't find a way to pass query parameters to the app as arguments using custom uri so that those are being passed to the underlying main method as arguments for us to process.
Example :
customuri://?somekey=value
when opened in a browser the app opens up with the parameters to be processed.

The application has to be registered to handle the URL invocation.
This is not related to install4j.
See
Handle custom URL schemes in an OS X Java application

Related

Pass arguments to application hosted by Appv but run up via Citrix

ok I'm no expert in this so I might explain wrong. We are trying to find a way to pass parameters to an app in appV but is launched by Citrix SelfService. So I guess when you have apps in appv you tell it you want to call an app by calling ctxAppVLauncher.exe and then pass it an app key of like "asdasd-123asd-asdd1234" etc etc... so to do that via Citrix selfservice you use the exe box for the txAppVLauncher.exe and then your params are the key... which then leaves you no where to pass in arguments for your real endpoint which for example you want to be notepad.exe but you want to pass notepad a text file path as an argument to auto open... there is no way to do that... at least none that we can find..
anyone have any experience with this ?

UI5 parameters: data-sap-ui-xx-waitfortheme and data-sap-ui-xx-componentpreload

The UI5 HTML-bootstrapper has two parameters which I don't really understand:
data-sap-ui-xx-componentpreload
data-sap-ui-xx-waitfortheme
I've checked the official documentation and didn't get some straightforward description.
My questions:
When should I use data-sap-ui-xx-componentpreload and what are its benefits?
When should I use data-sap-ui-xx-waitfortheme and what are its benefits?
⚠️ First things first ...
xx- options are experimental. They may be removed in future UI5 versions or their behavior may change in an incompatible way.
Option sap-ui-xx-componentPreload
By default, UI5 requests the app bundle Component-preload.js automatically when creating ComponentContainer (e.g. via data-sap-ui-oninit="module:sap/ui/core/ComponentSupport").
The bundle is generated by UI5 tooling for deployment so that users finally use the optimized version of the app. Therefore, avoid shipping the standalone app with data-sap-ui-xx-componentpreload in index.html! Otherwise, users will end up using unnecessarily the unminified, unbundled developer version of the app.
Options in index.html (data-sap-ui-*) don't affect typical Fiori launchpad (FLP) apps as FLP uses its own HTML page.
Using sap-ui-xx-componentPreload makes only sense for previewing, testing, or demo scenarios where there is no Node.js environment (unable to use UI5 tooling) so that 404-errors can be avoided. SAP Web IDE, for example, used to append the option sap-ui-xx-componentPreload=off in the URL so that the preview runs without the 404-error.
Values
async or sync by default depending on the sap-ui-preload / sap-ui-async settings.
off to load Component.js instead of Component-preload.js despite having a ComponentContainer.
Option sap-ui-xx-waitForTheme
The xx-waitForTheme option helps to avoid FOUC (Flash Of Unstyled Content) and, in some cases, to reduce sync XHRs. The option tells the app to postpone certain tasks until the theme has been loaded and applied.
Values (since UI5 1.63)
init waits for the theme → executes Core's init handler (attachInit(fn)) → renders the app.
Use this if some controls try to access theme-dependent parameters via sap/ui/core/theming/Parameters.get synchronously (deprecated) too soon.
rendering (formerly true until 1.62) executes Core's init handler first → waits for the theme → initializes the rendering.
If there is no value set, Core's init and initial rendering are executed immediately without waiting for the theme → FOUC.
For more options and information, see Configuration Options and URL Parameters and its parent topics.

Include runtime type definitions using VSCode extension

I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.

How can I access one Eclipse RAP entry point from another?

I have an Eclipse RAP 2.3 application with two entry points, say /first and /second.
In the GUI of the first entry point, there is a button with which I would like to open the second entry point in a new browser tab. The event handler of that button is currently
UrlLauncher launcher = RWT.getClient().getService( UrlLauncher.class );
launcher.openURL( "/second");
This already doesn't work when the application is deployed as myapp.war in a Tomcat web server (should then be /myapp/second).
My questions:
What's the best way to determine the URL to open within the event handler?
Do I have to fetch the HttpServletRequest, get the context path and so some string manipulation?
Is it actually safe to call RWT.getRequest() at this point?
Update
According to Rüdiger's comment I can acquire the context path in two different ways.
The first approach is
RWT.getRequest().getContextPath();
where RWT.getRequest() is documented with
This method is not recommended
Secondly, I could obtain it with
ApplicationContextImpl ac = (ApplicationContextImpl) RWT.getApplicationContext();
String contextPath = ac.getServletContext().getContextPath();
where the IDE displays the warning
Discouraged access: The type ApplicationContextImpl is not accessible due to restriction on required library ...\org.eclipse.rap.rwt_2.3.2.20150128-1013.jar
Despite the warning, it still works when deploying a WAR file with OSGi bundles to Tomcat.
So, in both cases there is some kind of warning, which makes the solutions look rather like workarounds.
Using RWT.getRequest() is not recommended because usually RWT would shield you from the lower-level servlet API and certain direct interactions with the request could even interfere with RWTs life cycle and yield funny responses.
While in your case it would be safe to access the ServletContext via RWT.getRequest(), I recommend to use
RWT.getUISession( display ).getHttpSession().getServletContext();
to access the servlet context.
The second approach accesses internal classes that aren't part of the public API and therefore shouldn't be use. The accessed classes may change or be (re)moved in the future without further notice and break your application.

How to suppress display of password in Selenium RC window

I am writing some Selenium RC tests using the perl library WWW::Selenium. At the beginning of the test I need to login to a web form using my username and password.
I noticed that my password is displayed in the Selenium Remote Control "Command History" window as type(password, secret).
Is there any way to suppress the display of the password? Maybe there is a command other than type I can use?
Unfortunately no. You could go into the Selenium core and change it to show ******* when it finds a field named password.
Beware though that this could make life difficult when debugging
I guess we can do this using native methods support.
Think logically every native methods in selenium will be sent to the operating system not to the browser.
So if you use any of the native methods, the flow is like this:
Client Program ----> Selenium RC server ----> to the operating system (in Java this is done using Robot Class)
But all the other non-native methods flow is like this:
Client Program ----> Selenium RC server ----> to the Browser
So, the Command History window operates at the Browser level and the native methods will not reach there.
Here is the code:
selenium.focus("locator");
selenium.keyPressNative("key code"); // this will not be shown in command history
Here the key code is only for one character and if you want string (more than one character), we should rely on our client program to implement the logic.
I have given that code in my previous answers to other posts. If you need it personalised post our exact requirement so that I can give that code tailored to your need.