How to clone settings ?

[freeman35 3]

Hello Uwe,

How to clone MMX settings to another system? "Sytem" mean, diffrent windows, diffrent IDE version. Which file and where is that (path & filename)?

I think for settings, ini file is always better then registry entry.  For multi user (OS) windows, this file(s) or path be in registry. otherwise under istall dir can be. This is my suggestion just.

Thank you, regards.

[Sherlock 663]

40 minutes ago, freeman35 said:

I think for settings, ini file is always better then registry entry. 

Amen to that! Every Tom, Dick or Harry writes something into the registry nowadays. It's just as cluttered as the good old win.ini was back in the day.

[Uwe Raabe 2064]

1 hour ago, freeman35 said:

I think for settings, ini file is always better then registry entry.

I actually think the same! Unfortunately it cannot be changed that easy. There are several places with registry access which have to be taken care of. Even the splitting in MMX and Shared, which have their roots in the common code between ModelMaker and ModelMaker Code Explorer, are a bit clumsy.

 

Also it will not going to be an INI file because of the hierarchical structure of the settings tree. I will probably choose XML. Don't expect that soon, though.

[Jacek Laskowski 57]

1 hour ago, Uwe Raabe said:

I will probably choose XML.

JSON is imho most human friendly 🙂

[Dalija Prasnikar 1404]

3 hours ago, Jacek Laskowski said:

JSON is imho most human friendly 🙂

But not very resilient to changes.

[Jacek Laskowski 57]

1 hour ago, Dalija Prasnikar said:

But not very resilient to changes.

what do you mean? give an example

[freeman35 3]

6 hours ago, Uwe Raabe said:

I actually think the same! Unfortunately it cannot be changed that easy. There are several places with registry access which have to be taken care of. Even the splitting in MMX and Shared, which have their roots in the common code between ModelMaker and ModelMaker Code Explorer, are a bit clumsy.

 

Also it will not going to be an INI file because of the hierarchical structure of the settings tree. I will probably choose XML. Don't expect that soon, though. 

No I'm not wait, ini file is better. And Have not to be one file. xml is not easy edit and easy find name&value, my vote to ini.

 

But no one share how to clone settings now :) registry or where is that ? This is much importend and main question :)

Thank you.

And sorry Uwe, I forget, thank you so much for much helpful project and shared it to free.

Best regards.

[freeman35 3]

I think I found that :)

under this reg key. All datas there. Export and import will be enough. ofcourse need install firstime.

HKEY_CURRENT_USER\Software\Raabe Software

[Uwe Raabe 2064]

2 hours ago, freeman35 said:

No I'm not wait, ini file is better. And Have not to be one file. xml is not easy edit and easy find name&value, my vote to ini.

Ini files lack proper structure support and MMX settings rely heavily on structure. For the purpose of your main question XML files would do pretty well - and not easy to edit is seen more as a feature here. 

[Dalija Prasnikar 1404]

12 hours ago, Jacek Laskowski said:

what do you mean? give an example

It means that if (more like when) data definition/structure changes, it is harder to provide backward compatibility support for JSON comparing  to XML.

 

Simplest example: { "id": 1, ... id is integer here... if you cannot easily change it to string. 

<id>1</id> - format stays the same, you can parse it like integer or like string. Of course, you cannot just parse "abc" as integer, but...

 

Also, XML structure can be more easily verified and you have greater options to manipulate and transform its content without parsing it first. You can also more easily pull only chunk of data and parse just that part. All that is probably not highly important for settings because that kind of data is usually not too complex or too large.

 

I don't want to hijack this thread... so... just wanted to say that choosing between JSON and XML is not as simple as it may look. It is not "JSON is always better" situation.

[Lars Fosdal 1793]

14 hours ago, Dalija Prasnikar said:

But not very resilient to changes.

From what point of view?

The standard XML parser barfs when a property appears that it is not aware of, while the TJson parser simply ignores it - so in that respect, Json appears as more resilient than XML.
Edit: FYI, We generally pass most, if not all, numeric values as a string, since that gives us the NULL we need for numeric values as well.  

[Dalija Prasnikar 1404]

25 minutes ago, Lars Fosdal said:

From what point of view?

The standard XML parser barfs when a property appears that it is not aware of, while the TJson parser simply ignores it - so in that respect, Json appears as more resilient than XML.
Edit: FYI, We generally pass most, if not all, numeric values as a string, since that gives us the NULL we need for numeric values as well.  

That part solely depends on a parser. 

[Lars Fosdal 1793]

1 minute ago, Dalija Prasnikar said:

That part solely depends on a parser. 

True. But changing the type of an xml field also requires the consuming xml parser to know that type has changed.

So - if your client used the field as a number, converting the value into a double or integer - changing the content to a string would still be a breaking change, right?

Hence, that is not really a feature of the format, since the actual interpretation depends on convention i.e. specification of parsing- and if the specification has changed, and your parser is still using the old spec - it breaks.

But, yeah - we are off topic.