[Valentina] Re: Vdb files

[Robert Brenstein]

>Hi Ruslan,
>
>>>  Does this make sense?
>>
>>  I afraid no.
>>
>>  You forget that THE SAME source code must work on MAC without extension, on
>>  Windows with extension.
>>
>>  So
>>
>  >> ValentinaSetExtensions "", "dat, "blb", "ind"
>>>  db.Create( "dbname" )
>>>
>>>  To get files:
>>>   dbname 
>>>   dbname.dat
>>>   dbname.blb
>>>   dbname.ind
>>
>>  Is not good idea, because this code on Windows ALSO will create file with NO
>>  extension, but we need it. You see?
>
>Only if I specify the extension as "".
>
>As a developer, I should have control without these confusing and convoluted
>rules. In order to ensure Win32 extensions you make an otherwise
>straightforward process confusing.
>

I agree with Keith, Ruslan. You seem to make it more complicated than 
needed. It is clear to me that the behavior must be system-dependent 
(carbon apps must resolve this at execution time, others can have it 
set is as a compilation-time constant).

a) default behavior without ValentinaSetExtensions:

Windows: default extensions for all files
Mac OS: no extension for vdb, extensions for others; creator & type
Mac OSX: default extensions for all files + creator & type

b) if ValentinaSetExtensions were called, do as above but:

- use user-defined extensions when non-empty except:
- accept empty (no extension) for vdb file on Mac OS and OSX.

If db.Create() gets a name without extension, the above rules apply. 
If an extension is provided, it implicitely sets the extension for 
(and only) the description file (overwriting default and 
ValentinaSetExtensions).

The latter means that, using Keith example, if I say (under Mac OS)

   ValentinaSetExtensions "XXX", "dat, "blb", "ind"
   db.Create( "dbname.vtc" )

I get

dbname.vtc
dbname.dat
dbname.blb
dbname.ind

This way, ValentinaSetExtensions allows us to define non-standard 
behavior as it was intended and the rules are straightforward and the 
results are always predictable.

Well, my 2 cents.

Robert Brenstein