i have the executable files, now how to create the GUI

[maverickalex]

i was getting confuse as to how to choose the "options" (better than variable)

At the end i need to be able to press go and create the script that will be equivalent

finding the path to the particular tool. which we can as discussed either create a menu and include the tools in that, or

Code: Select all

answer file "Please select the path to your toolset" 
   put it into tPath 
   if tPath is not empty then 
      put tPath into tWinPath 
      replace "/" with "\" in tWinPath 
   end if 
   put tWinPath into field "fldToolsetPath"

next is needed the specific file we are choosing to modify.
in the initial example it's something like w070n10.hgt.zip i would need to find that file.

Then the output file. direct the program to output to that file.

and then a big button that puts them all together like this example.

Code: Select all

set PATH=e:\flightgear\terragear;%PATH% 
hgtchop 3 e:\flightgear\terragear\N07W071.hgt.zip e:\flightgear\work

and allows the command to be started.

I know the design keeps changing but i'm trying to figure out the best way for it to work.



For number 1 i have the following script.

Code: Select all

on mouseUp
   answer file "Please select the tool you require" 
put it into tPath 
if tPath is not empty then 
put tPath into tWinPath 
replace "/" with "\" in tWinPath 
end if 
put tWinPath into field "toolsetchoice"
put field "toolsetchoice" into field "finalchoice"

end mouseUp

for number two is field "toolsetchoice"

number 3 is the "options" field
number4 is the "fileselect" and has this script

Code: Select all

on mouseUp
   answer file "Please select the file you require" 
put it into tfilechoice 
if tfilechoice is not empty then 
put tfilechoice into tWinPath 
replace "/" with "\" in tWinPath 
end if 
put tWinPath into field "filechoice"
put field "toolsetchoice" && field "options" && field "filechoice" into field "finalchoice"
end mouseUp

number 5 shows the file selected.

number six is Field "finalchoice"a text box to show the user all they have selected so far.
i hoped that adding this to the script above would do it.

Code: Select all

put field "toolsetchoice" && field "options" && field "filechoice" into field "finalchoice"

which it does, but i get eroneous number ones

ie between the options selection and the file selection there are two number 1's that i havent asked to be there, gatecrashers if you will!

number seven is the button to initiate the full command, i havent worked tht out yet. I also need to add the output file select as well.

as i mentioned its the options field that gives me a headache. In total there are about 30 different options for the 20 tools.

would it be easier to create a new stack for each tools options? how would i go about that.
I'm semi impressed with myself as i think i am picking up stuff fairly quickly, but i know i have barely started.

[maverickalex]

As you can see there are two unwanted 1's in the textbox, i don't understand why they are there.

It looks like i am going have to run a seperate stack for each tool.
As i think the order in which the tool runs changes for each one.

In some tools, its the path to the tool first then the work directory, then options, then the output directory.
in others it's the path to tool, then output path, then options etc. Which makes things more complicted i'm sure.
I'm sure there will be the ability to create some sort of order in Rev, i'm reading up as i type.

Thanks for putting up with my quest

Alex

[SparkOut]

Hi Alex,
I really don't have the first clue about what your tools are and what they actually do, but I'm beginning to see that there are a mass of tools and paths to select, which from the point of view of keeping things simple for a user, I'm thinking would be best to have collected in one toolset folder (whether in subfolders or not) that have a default location, placed there as an installation action. Then you can use the "menu" approach to selecting the tool required, which your app will know where to find relative to the executable application itself. (The location can always be browsed under an "advanced" option if necessary, and recorded in a preferences file, but you're probably going to make things a lot simpler for yourself and your users if the tools are in a default location.)
I would suggest that for clarity, on selection of a menu item, you switch to a separate card with the default settings for that tool shown, and any optional settings to be configured there. There's no need to make a separate stack. Make the choices available as basic as possible (eg if there are two options, of the "on/off" variety, make it a checkbox, if there is one of a specific set of values to be chosen, make it a radio group. If it is a range say 1 to 10, perhaps a slider control.) Don't give the user an option to freetype something that may cause unwanted effects or crashes, by putting a field in view, if a fixed and limited range can be set, especially with defaults.
The order that you run the options can be different on different cards, but I'm wondering exactly what you mean here, as the options will presumably need to be set before you kick off the tool with the shell command, won't it?

[SparkOut]

As to the extra 1's shown - I wonder if you just go into the message box and type 'put field "options" whether you get :
3
1
1
shown? If you click in the field and use the down and up arrows, can you see anything but the 3? My first guess is that you have on occasions hit "return" in the options field, which has moved the text onto a new line and made the (single line) field look like it's empty, but still has other lines of data in it.
In the property inspector you can tick the box that says "tab on return" to change that behaviour so that if someone presses the return key while in the field, then the focus switches to the next focussable object. (The order of the focussable objects is determined by the layer each has, on the size and position pane of the PI.)

[maverickalex]

I really don't have the first clue about what your tools are and what they actually do,

Snap!!

In laymens terms, the tools basically extract different data files from zipped files.
because they are not widely distributed files they need different tools to extract the information And convert it.

The toolset are all in one folder called Terragear.

There are actually not that many paths to select as they all reside in the one folder.
The user will have created several output folders prior to using this application (or at least thats what you have to do now)
so that the outputted files are in the correct place.

My original thoughts were for the seperate card for each tool options so that fits in well.

In order for the correct data to be output the options need to be set in the correct order, some are minimum or maximum figures, others are required for the type of data thats ectracted.

If i could possibly divert your attention momentarilly and divert you to
http://wiki.flightgear.org/index.php/Ho ... on_Windows

that is the current tutorial/wiki article in using the command line structure, which is what i want to get away from.
The whole reason i decided that it was time to create a GUI was because it just seemed so complicated to try and run command lines all the time especially if your not used to it.
Being an open source project as well means that the more people we can get involved with the development the better.
Hence this tool, there are people that would love to create or modify the terrain we have to be more realistic (which is what Terragear Tools does)
but they shy away because of the difficulty accessing the data.

I am a bare novice when it comes to programming, i know some xml, but i'm prepared to learn and invest the time to do so

Thanks very much
Alex

[maverickalex]

As to the extra 1's shown - I wonder if you just go into the message box and type 'put field "options" whether you get :
3
1
1
shown? If you click in the field and use the down and up arrows, can you see anything but the 3? My first guess is that you have on occasions hit "return" in the options field, which has moved the text onto a new line and made the (single line) field look like it's empty, but still has other lines of data in it.
In the property inspector you can tick the box that says "tab on return" to change that behaviour so that if someone presses the return key while in the field, then the focus switches to the next focussable object. (The order of the focussable objects is determined by the layer each has, on the size and position pane of the PI.)

I am a complete "Numpty"

that's exactly what happened.

[SparkOut]

In order for the correct data to be output the options need to be set in the correct order, some are minimum or maximum figures, others are required for the type of data thats ectracted.

If i could possibly divert your attention momentarilly and divert you to
http://wiki.flightgear.org/index.php/Ho ... on_Windows

That link seems to be temporarily inaccessible to me - I'll have another check tomorrow, but I'm guessing that what you mean is that the parameters and options need to be given to the tools in a particular order? It doesn't actually matter what order you set the options on your card, as long as they are all set and collected in the right order when passed to the shell command to execute the tool with the provided arguments - does it?
So you can have a consistent look/feel on the cards about what paths and options to set in a standard order. It'd just be up to you to collect the information in the fields and controls that the user has set, and provide them as arguments to the tool in the right order. The tool won't know anything about it until you press the button telling it to run, and before the line in the button script that kicks off the shell command, you can error trap to make sure that all required options are set and within range.
Is that making sense or have I missed the point?

[maverickalex]

NO that makes perfect sense. I'm sorry if i have become a pain already, despite two days ago sayng i wouldn't.

I obviously want to make it as simple and easy to use as possible. Your comments are very welcome and your knowledge a blessing..
Feedback is a gift!

Thanks,
I shall have a try at implementing your recommendations.

Alex

[SparkOut]

You're doing very well Alex - don't feel embarrassed at all. It's quite clear you're not a pain, and definitely looking to learn, not offload the effort of making a script/application onto someone else. Don't consider yourself a pain in any way. (I actually find myself learning the most, through helping in this way as much as I can.)

[maverickalex]

Thanks. Its a pleasant change to feel welcomed. i appreciate yours and everyone elses help and support.

[maverickalex]

Ah some good news today at least.

I have no need to create 20 tools now, only four. so there's not as many option to have any more.

Which is a blessing

[maverickalex]

i have createda tools menue with the four tools i need.

Its a simple pulldown which when i click on the tool would like it to open the card relating to it's options.

for the tool hgtchop i have created a card "hgtchop options"
I have the script (thus far) for the menu set as this,

Code: Select all

--The following menuPick handler was generated by the Menu Builder.
on menuPick pChoice
   switch pChoice
   end switch
end menuPick
break
     case "HGTchop"
        on OpenCard 
           get card  "hgtchop options"
           end Opencard
    break
  case "Terrafit"
    --Insert script for Terrafit menu item here
    break
  case "Genapts"
    --Insert script for Genapts menu item here
    break
  case "Shape-decode"
    --Insert script for Shape-decode menu item here
    break
  end switch
end menuPick

Which although gives no errors is quite clearly wrong as it is'nt opening the card hgt options.
i know it basic, where am i going wrong.

[SparkOut]

Did the menu builder make that? Not very helpful if so!

Code: Select all

on menuPick pItemName
   switch pItemName
      case "HGTchop" 
         go card "hgtchop options"
         break 
      case "Terrafit" 
         --Insert script for Terrafit menu item here 
         break 
      case "Genapts" 
         --Insert script for Genapts menu item here 
         break 
      case "Shape-decode" 
         --Insert script for Shape-decode menu item here 
         break 
   end switch
end menuPick

Should tidy up the script a bit. Nothing was working before, because you had the on menuPick handler start the switch choice options and then immediately end the switch, and then immediately end the menuPick handler. Also you don't want an "on openCard" handler there in the menu, you want to "go" to the destination card. The card, when it opens, can have an on openCard handler which may set default options, for example, but that would go in the script of the card, not in any menus.

[maverickalex]

that worked thanks, when i check the script and it askes to confirm the handler with menupick, it brings up another box to input pItemName.

Do i need to input anything into that specifically or can it be left blank?

I just lost a whole mornings work, when my systems crashed

[SparkOut]

Saving and backing up is always a good thing. I'm sorry it's happened though.
Anyway, if you're testing the script in the debugger/script editor, then running the handler it will not know what option was chosen, so you can pass it one of the menu items like this.
In normal operation (including in the IDE while developing the app) when you select one of the choices in the menu button, the chosen item will be passed to the handler as the pItemName parameter. So if you click the button and select "HGTchop" then the menuPick handler will trigger and pItemName will contain "HGTchop" - so that the handler can react according to what item was selected from the menu.