[Solved] How to know selected filter in a SaveAsDialog?

Hey happy people,

I’m creating an Export feature in my app that will export a list to CSV.
The SaveAsDialog has a Popupmenu containing two filters so the user will be able to choose between two different formats for export. (see picture)

My issue is how to know what the user choose in the Popupmenu?
The example in the LR suggests to use this:

  If Right(f.Name,3)="txt" Then
    MsgBox "1"
  Elseif Right(f.Name,3)="htm" Then
    MsgBox "2"
  End if

However, this does not work in my case since both two formats use .csv as the file extension.

Any ideas?

You can always match it against the same string you’re using to populate it in the first place, no?

I’ll refrain from complaining how “CSV” is a misnomer if the separator is not a comma, since I know the world has moved on on this :slight_smile:

[quote=28196:@Eduardo Gutierrez de Oliveira]You can always match it against the same string you’re using to populate it in the first place, no?

I’ll refrain from complaining how “CSV” is a misnomer if the separator is not a comma, since I know the world has moved on on this :)[/quote]
Great, I’ll try that!
The reason for the two options is that Excel does not seem recognize the file as a CSV unless it’s separated with a “;” :confused:

Whilst I cannot give you a definitive answer to your question I have the same problem.

My solution is to store the actual delimiter in a preference in my application. This can be changed by the user and his last chosen delimiter is stored and used each time. The actual text file produced will use one of three delimiters (comma, semi-colon or tab). Using this method means that I do not give the user the opportunity of selecting a filetype in the dialog and just save as a CSV file.

[quote=28199:@Simon Berridge]Whilst I cannot give you a definitive answer to your question I have the same problem.

My solution is to store the actual delimiter in a preference in my application. This can be changed by the user and his last chosen delimiter is stored and used each time. The actual text file produced will use one of three delimiters (comma, semi-colon or tab). Using this method means that I do not give the user the opportunity of selecting a filetype in the dialog and just save as a CSV file.[/quote]
That is one way of doing it. I was thinking about having multiple choices in the Export menu for the different formats.

HA! I Actually managed to solve this one in a way that’s probably not the “best practice” way, so if there’s another solution let me know.
Until then, this does seem to work. I add an empty(?) chr(127) at the end of the extension for one of the formats.
This is not visible for the user but it’s valid to test against somehow.

  Dim csvTypeComma as New FileType
  csvTypeComma.Name = "CSV Comma separated (*.csv)"
  csvTypeComma.MacType = "TEXT"
  csvTypeComma.Extensions = "csv"
  
  Dim csvTypeSemicolon As New FileType
  csvTypeSemicolon.Name = "CSV Semicolon separated (*.csv)"
  csvTypeSemicolon.MacType = "TEXT "
  csvTypeSemicolon.Extensions = "csv" + chr(127) '<-- LOOK HERE
    If Right(f.Name,3)="csv" Then
      MsgBox "1"
    Elseif Right(f.Name,4)="csv" + chr(127) Then
      MsgBox "2"
    End if

Then I’ll just set the extension of the created file back to “.csv” thus removing chr(127).

I like that!

In my apps I’ll have to use a series of ‘hidden’ chars at the end but the idea is good.

I agree that the solution is probably ‘not good’ but, if it works, so be it!

This is usually related to regional settings. In a country where commas are used for decimals or thousands Excel will usually replace them for semicolons. It does the same thing to formulas, where parameters are separated by “;” instead of “,”.

I use tabs myself. Works in every location.

SInce when does EXCEL not recognize “,” in a CSV? By DEFAULT that it the delimiter for a CSV File

A PROPER CSV doesn’t have to worry about regional setting… since IF there are number containing “,” they had better be inside of QUOTES or they do not meet the proper CSV requirements

[quote=28248:@Eduardo Gutierrez de Oliveira]This is usually related to regional settings. In a country where commas are used for decimals or thousands Excel will usually replace them for semicolons. It does the same thing to formulas, where parameters are separated by “;” instead of “,”.

I use tabs myself. Works in every location.[/quote]
Aah, that’s why! When I export to CSV in Excel it says “Colon separated file”(but in swedish…) but actually produces a “;”-separated CSV.

Corrected myself above…

I added an export option as TAB separated too :wink:

EDIT: The text below turned out to be unnecesarily long-winded. Feel free to skip it, as it’s not like this is such an important topic. I’ll leave it untouched, but in a way I wish I hadn’t written it. It feels weird having strong feelings towards a text file content format :slight_smile:

[quote=28251:@Dave S]SInce when does EXCEL not recognize “,” in a CSV? By DEFAULT that it the delimiter for a CSV File

A PROPER CSV doesn’t have to worry about regional setting… since IF there are number containing “,” they had better be inside of QUOTES or they do not meet the proper CSV requirements[/quote]

While CSV is a convenient shorthand for a type of file content definition, there is not a PROPER CSV format, as CSV is not a format. The “csv” extension wasn’t even common until Excel “formalized” it (although comma-separated lists have been common since the days of punch cards).

Even so, one of the most common conventions of “CSV” is that integers and floats are never double-quoted, strings (which might have the separator) usually are (except for Excel, which doesn’t double-quote anything ).

Since CSV is, in the end, a TEXT format, there’s no abstraction of value and format. In european countries this usually means decimal numbers are shown as 123,45 instead of 1234.45 and programs will dutifully export floats unquoted and with commas.

So, if normal CSV (as understood by Excel, if we want to go that way) doesn’t quote floats or integers and the values saved are regionalized, then it becomes immediately obvious that “comma” can’t be used as a separator in places where floats contain commas for decimals. In these regions Excel exports (and imports) using semicolon by default, just as it uses semicolons in formulas.

I wish CSV was an actual format, but it isn’t. And the place where CSVs are used the most by end users, Excel, agrees with me here: Floats and integers are never double-quoted, regardless of the regional setting, but the default separator is changed.

I personally prefer to use tab or pipe separated fields, myself. Always thought using a character as common as a comma was stupid after 1990.

Wikipedia also agrees with me, for what that is worth: A comma-separated values (CSV) (also sometimes called character-separated values, because the separator character does not have to be a comma)

The original CSV format quote fields (which means commas were forbidden) and when it “evolved” (not as a standard, but out of common sense) double-quotes were added to strings, not to all fields or to fields whose content has a comma, since space and memory was at a premium. It was also designed around 7-bit ASCII and period decimal separator since it was american-centric (not a bad thing, in itself).

The CSV format, nowadays is a bit like setting up modem handshake settings: If CSV is agreed, then other things need to be agreed along with it: Line terminators, encoding and separator, quoting and escape characters.

The 2005 RFC4180 defining CSV, while well-intentioned, comes almost 50 years after the format has been in common use, but recognizes the chaotic nature of this “non-standard standard” by leaving pretty much everything optional (and the only thing it sets as a rule, which is that quotes within quoted fields should be escaped by prepending another quote, is summarily ignored by every program I have encountered in the last 30 years).

IANA corrected all the glaring ommissions and limitations of CSV by pretending it didn’t exist and defining the MIME type “text/tab-separated-values” only, but the Internet Society brought this hellspawn back in 2005 by requesting registration of “text/csv” in the RFC above.

Agreeing on using CSV is like agreeing on going to watch a movie with others. Even when agreed several things still need to be defined and confirmed.

Thank you Eduardo for clearing things up about CSV. Taught me a lot :slight_smile:

The problem with checking the extension of the Name property, is that the SaveAsDialog does not always append the extension.

When I click on the “Save” button in the above window, then Name = “cube” instead of “cube.x3m”, so there is know way of knowing which filter was selected?

<https://xojo.com/issue/29204>

Perhaps the selected filter could be returned by an optional parameter in the ShowModal method of the dialog? E.g.

myFile = dlg.ShowModal(theFilter)

That way you know exactly which filter was selected.

Hi Alwyn,
That might be correct for Windows but on OS X the behavior you’re seeing isn’t there.
On OS X if the extension isn’t in the filename it’s added automagically :slight_smile:

PS. My app is Mac-only

Thanks for the info Albin.

Seems to be a Windows issue then… and updated the feedback case accordingly.

I need to publish my app across the board (Windows, OS X and Linux)… so guess I’ll have to sit tight until this one gets fixed.

You have a point there that it must work in a better way since my solution seems somewhat freaky :wink:

Ok, I don’t see this problem.

I have file types defined in the FileTypes1 section in the IDE for my app. When I do a SaveAsDialog and check the resulting FolderItem, the appropriate extension has been added to both the Name and DisplayName property, as well as to the path properties, even if I don’t specify it in the dialog’s filename field.

I’m running Windows 7, Xojo 2013r2.