Javadoc for javadoc com.install4j.runtime.beans.formcomponents.DirectoryChooserComponent - install4j

I want to set starting directory for DirectoryChooserComponent in my initialization script but I don't see the javadoc for this anywhere.
Should I not access this component directly?

Solution: DON'T DO THAT.
Instead, use setVariable action to set a variable earlier and then use that in the field for initial directory in the UI.

Related

Assign build clean option at queue time

i have a bitbucket classic build pipeline and i need to have the ability to set the build clean option at queue time. it seems like this used to be possible via the Build.Clean variable but that has since been deprecated.
When editing a build pipeline the Clean option uses an editable drop down but anytime you try and type something, it erases what you just wrote. i would like to set this option to a variable like $(CleanBuild)
Assign build clean option at queue time
Indeed, the variable Build.Clean is already deprecated. But the document Use predefined variables provided another variable Build.Repository.Clean, which will help us to clean the Sources:
Besides, if you want to clean other options fields, like All build directories:
I do not believe there is a way to assign the clean options at queue-time. Even if we use deprecated Build.Clean variable, we still can clear Sources only.
You could check the similar thread for some more details.
Hope this helps.

Get NetLogo widgets in headless mode

I need to get the list of all defined widgets in a nlogo script in headless mode. I basically need to the targeted variables and the default values. But I just find private methods in the API to achieve this (https://github.com/NetLogo/NetLogo/blob/5.x/src/main/org/nlogo/headless/HeadlessModelOpener.scala#L136-L234). Is there a public method from the API to achieve this ?
Thanks
Mike Horn solved this by parsing through the .nlogo file in his NetTango project. If you're okay with that, take a look at his Model.java load() method, and initSlider(), initSwitch(), and initPlot() methods. I don't remember the exact relative line location of default value for the other widget types, but if you open a .nlogo file in a text editor, you should be able to figure it out.

In eclipse debugger, variables view, can I change "Value" value

I wonder if there is a way to change what we see in Value in Variables view in eclipse debugger?
For example instead of "ObjectClass (id=94)" I would like to see what that object toString() method returns, is it possible?
(I know that in "Expressions" we can add variable.toString() and it will show it, but I must add it manually, over time is tedious).
Yes you can do this by using your own debug detailed Formatters. Check here that the Person object is changed from Person(id=38) to Name=John Surname=Smit.
Also refer this link.

Missing link between objectContribution and command

When using the objectContribution-element (which is part of the org.eclipse.ui.popupMenus-extension point), I often (practically always) want to delegate to some command instead of implementing some action myself (since usually, I have the command and a handler already implemented). I'm doing this by using ICommandService and IHandlerService, but it feels there should be a way to achieve this programmatically. I could use viewerContribution instead of objectContribution, but then I would lose the easy way of showing the menu entry only when certain object types are selected. Ideally, I would like to use the enablement-checks that already exist for my handlers to apply to the menu entry defined by the objectContribution.
Ok, here's what I was missing: instead of using the org.eclipse.ui.popupMenus-extension point, I had to use the org.eclipse.ui.menus-extension point with a menuContribution that has its locationURI-attribute pointing to popup:org.eclipse.ui.popup.any?after=additions. This menuContribution can include a command-element (achieving the goal of binding directly to an existing command), and this command-element´s visibleWhen-element can be bound to the activation status of the bound command's handler via the checkEnabled-attribute (achieving the goal of having the popup-menu entry visible only when the enablement for the command handler is satisfied).
What's bad is that the documentation of the org.eclipse.ui.menus-extension point states that the org.eclipse.ui.popupMenus-extension point is to be considered deprecated, but the documentation of org.eclipse.ui.popupMenus does not mention this fact.

Global launch configuration in Eclipse?

This seems like a simple thing, but I can't find an answer in the existing questions:
How do you add a global argument to all your present and existing run or debug configurations? In my case, I need a VM argument, but I see that this could be useful for runline arguments as well.
Basically, every time I create a unit test I need to create a configuration (or run, which creates one), and then manually edit each one with the same VM argument. This seems silly for such a good tool.
This is not true. You can add the VM arguments to the JRE definition. This is exactly what it is for. I use it myself so that assertions are enabled and heap is 1024mb on every run, even future ones.
Ouch: 7-years bug, asking for running configuration template, precisely for that kind or reason.
This thread proposes an interesting workaround, based on duplicating a fake configuration based on string substitution:
You can define variables in Window->Preferences->Run/Debug->String Substitution. For example you can define a projectName_log4j variable with the
correct -Dlog4j.configuration=... value.
In a run configuration you can use ${projectName_log4j} and you don't have to remember the real value.
You can define a project-specific "empty" run configuration.
Set the project and the arguments fields in this configuration but not the main class. If you have to create a new run configuration for this project select this one and use 'Duplicate' from its popup-menu to copy this configuration.
You have to simply set the main class and the program arguments.
Also you can combine both solutions: use a variable and define an "empty"
run configuration which use this variable. The great advantage in this case
is when you begin to use a different log4j config file you have to change
only the variable declaration.
Not ideal, but it may alleviate your process.