vbgunz
24th December 2003 15:49 UTC

Feature Request: Simple, new label within INI's to making referencing fields easier.
Hello,

I've created some custom screens for my installer but noticed a downfall to the design behind the INI's. It seems once all fields are referenced by their field number it becomes trivial and quite hard when trying to re-design the custom screens and stay in sync with the mappings.

This could already be implemented and I might have missed it or if this is not implemented I believe it would help very much in the custom screen development. It should in theory work quite easy.

Instead of mapping to field numbers, how about to field labels? Currently we have type=label but this should be a world different than label=type. I mean the following would probably make more sense.

[Field 1]
Field=firstName
[Field 2]
Field=middleName
[Field 3]
Field=lastName
[Field 4]
Field=nickName

Instead of linking to field numbers devs can link to something meaningful such as "fisrtName". The biggest benefit is the freedom behind designing custom screens. A dev can make one screen with a few fields or later design the same screen with dozens. Since field numbers can change at any given time a good anchor would be a label=name.

This is basically only to help out in regards to custom screen development. Forgive me if this is already implemented and I managed to miss it before this post.

Otherwise I would really like to hear what others have to say about this. Could this be implemented? What would make it better? Really curious, thanks for reading :)

Joost Verburg
24th December 2003 16:06 UTC

The best solution would be to let InstallOptions enumerate the INI sections so you can use any name you want and don't have to set the number of fields.

However, this will break backwards compatibility because it was possible before to put the sections in any order.

vbgunz
24th December 2003 16:21 UTC

Hello Joost,

How about adding an *option* to create a label and still maintain backwards compatibility? I mean devs can simply be given two choices. To either link to field numbers or field labels. Labels though will seriously have their advantage as then INI screens can be freely edited in applications like HM NIS EDIT without worry.

Currently linking to numbers gets the job done but basically gets the job done once. I mean after all field numbers have been referenced it seriously becomes a mind boggling puzzle in trying to redesign the custom screen, all while trying to maintain sync with the mappings of each field.

I am not saying the current method is not good enough, I guess I mean the current method is quite limited. It would be nice to see an option to link to either numbers or labels. Linking to labels should allow a more dynamic design experience and really should just help to speed things along.

I hope you reconsider the thought, I am so brain tired now I really cannot fight it any longer... Sorry, would really love to hear more on your thoughts about this.

Thank you Joost, for your time and everything else :)

Joost Verburg
24th December 2003 17:53 UTC

Keeping two different methods is not such a good idea. It will increate the installer size and and make it difficult for editors.

Vytautas
25th December 2003 05:43 UTC

Joost, I'm not sure how it would break the backward compatability. Don't the sections have there designated positions on the screen, top left right bottom. Then does it really matter in what order they were created or not.

Vytautas :)

PS. I am assuming you meant that IO would enumerate all of the sections in an ini file and then you could use the section name as the label.

[FirstName]
...
[MiddleName]
...
[LastName]
...

etc.

vbgunz
25th December 2003 09:41 UTC

Hello all,

Actually, letting InstallOptions enumerate the INI sections is ok. Every field will have a number and they will be ordered accordingly.

My suggestion is simply *adding* a new label devs can link to instead of having to be faced with linking only to field numbers.

Here is a really good example. Create a custom screen with 10 fields. Then map those fields to 200 !insertmacro ReplaceInFile's.

Got it? Now remove only field 1 from the custom screen. Do you see the hell you've just caused with the script?

Everything above field 1 has just gotten re-ordered and this means over 200 lines in the script have to be modified to compensate.

This is bad in a sense. It only truly allows a one time design. After the initial design, re-designing can quickly become really redundant.

So it will still look like this...
[field=1]
...
[field=2]
...
[field=3]
...

But hopefully insteading of mapping to field numbers, link to field labels like this...
[field=1]
label=firstName
...
[field=2]
label=middleName
...
[field=3]
label=lastName
...

This way if field 1 is removed "firstname" and all fields get re-ordered, meaning field 2 is now field 1, this shouldn't matter one bit to mappings because we're linking to labels.

If this makes sense hug it, if it doesn't I'll really try to make it a bit clearer. I know sometimes I can easily cause confusion so I apologize. I hope though now it is a bit more clear.

Tell me what you think, I'll be happy to learn more about your thoughts on it :)

Vytautas
25th December 2003 10:41 UTC

vbgunz, your suggestion will require a complete redesign of how the IO actually works, where I think that my idea of allowing the developers to use any name instead of 'field x' would simply require that the IO read the ini file differently. Therefore the old scripts should still work as 'Field 1' would still be a valid name for a section and the devs would be able to use more descriptive field names.

Vytautas

vbgunz
25th December 2003 10:51 UTC

Hello Vytautas,

To be honest, if any way other than linking to field numbers is to be introduced I know it can seriously make an impact on re-design time.

Linking to numbers is good at the moment but it can cause a big headache the second all fields get re-numbered. This is almost always guarenteed to happen too... Sort of like the rash that keeps coming back :)

I believe linking to field labels is a much better option as it will allow more dynamic and intuitive approaches in custom screen development.

Thanks for your positive feedback Vytautas, I hope something like linking to field labels is introduced when ever the time permits :)

kichik
25th December 2003 13:05 UTC

You can simply create a few defines which will hold the field number. This way, you'd only have to change it in one place and not the entire script. For example:

!define firstName "Field 1"
!define middleName "Field 2"

#...
WriteINIStr io.ini "${firstName}" "state" "victor"

vbgunz
25th December 2003 15:08 UTC

Hello Kichik,

I believe in theory Kichik's solution will not work too well with re-designing an INI.

e.g. If "field 1" is firstname and "field 2" is middlename, and upon redesigning we decide to either change firstname to nickname or completely remove it, your solution will still confuse the script.

Your solution will simply make nickname the firstname or *if* we've simply removed it, your solution will turn middlename into first name and all other values will fall into a domino law.

Kichik, your work and effort is impecabble and incredible. I might have your solution completely wrong. Please correct me if I made an error.

I just learned from my flash days to never rely on numbers but labels instead. This method insures dynamics do not interfere with flow.

I'd like to know what you think and if I got you wrong on your solution, please correct me. Thank you Kichik!

kichik
25th December 2003 15:35 UTC

Redesign will indeed still confuse the script but it will be a lot easier to fix. You will only have to change one line instead of the entire script.

vbgunz
25th December 2003 16:01 UTC

Hello Kichik,

Yes, your solution is much better than linking directly to field numbers. I can see it's advantages, thank you for the insight. Until an actual label system or something like it is ever put into place I will steadily prepare my scripts as according to your solution for GP.

In actuality, I did not need the field label feature when I mentioned it and still do not need it now. I only mentioned it as further on down the road I would like to do some re-designing... Just when I thought ahead about it, it sort of spooked me :eek:

I hope this gets implemented sometime in the future of NSIS.

Thanks Kichik!

Joost Verburg
25th December 2003 21:39 UTC

Currently, the order of sections in the INI file is not important. People can put Field 2 before Field 1 and still get the correct tab order.

If you enumerate sections, this will break backwards compatibility.