Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[Dltk-dev] Re: Extending and increasing visibility for members of AbstractScriptInterpreterDialog

I am not sure I understand why this cannot be performed in your dialog class.
Also, interesting question is if language has several install types, e.g. for ruby they are Generic Ruby and JRuby.
Should the environment block show/hide in the dialog if I change the value in combobox? :-)

If the environment variable is required only in some cases and you don't need user to modify it, then you can add it in AbstractInterpreterRunner.

As I already written arguments could be specified in AbstractInterpreterRunner too, so what exactly remains in the "other stuff"?

Regards,
Alex

----- Original Message -----
From: "Gabriel Petrovay" <gabipetrovay@xxxxxxxxx>
To: alex@xxxxxxxxx, "dltk-dev" <dltk-dev@xxxxxxxxxxx>
Sent: Friday, April 17, 2009 3:03:06 PM GMT +06:00 Almaty, Novosibirsk
Subject: Re: Re: Extending and increasing visibility for members of  AbstractScriptInterpreterDialog

Hi again Alex,

Regarding the EvironmentVariablesBrock, you are right, it could be made like that. But as I wrote in the initial e-mail:

This CANNOT be performed in the extended MyAbstractScriptInterpreterDialog class because this should not be aware of the install types. Moreover Install types from the parent dialog class are not visible from the inheriting classes. But even if you increase the visibility of install types combo or provide accessor methods, I guess you don't like to see code like the following:

    @Override
    protected AbstractInterpreterEnvironmentVariablesBlock createEnvironmentVariablesBlock(AddScriptInterpreterDialog dialog) {
        if (Platform.getOS().equals(Platform.OS_WIN32))
            return null;
       
        String[] names = getInstallTypeNames();
        for(...) {
            if (names[i].equals("MyInstallType1")) {
                return null;
            } else if (names[i].equals("MyInstallType2")) {
                return new MyInterpreterEnvironmentVariablesBlock(this);
            }
        }
    }

I guess this is not the most elegant way to solve the problem. The InstallTypes are aware about variables and therefore they should be asked if they needsEnvironmentVariables()

Does this make sense?


What about the other stuff?

Regards,
Gabriel


--
MSc Gabriel Petrovay
MCSA, MCDBA, MCAD
Mobile: +41(0)787978034

Back to the top