Some comments.
1) Please attach the patch to the bug rather than referencing an external file.

2) You use g_warning in several user visible areas.
eg   g_warning(_("Field specification must be a comma separated value (Name,Type,Size,Prec)."));
please use gnumeric_io_error_string as you do elsewhere.

3) Would it be helpful if the user could specify an encoding in the file dialog ?
or it ok to hard code the encoding
+       PX_set_parameter(pxdoc, "targetencoding", "CP1252");

4) Is there no way to have PX_create_file or it's brethren go directly to gsf rather than creating a tmp file ?

5) Is it helpful to keep the importer and exporter in 1 source file ?  In most of the other plugins there are -read.c and -write.c

Thanks for the comments. Here are my answers:

1. No problem

2. I wasn't sure if gnumeric_io_error_string is always apropriate. I will change that.

3. It would be helpful, but I just don't know how to do it. Is there an exporter I can look at?

4. Writing a file requires to jump around in the file and reading other parts. According to Morten this isn't possible. He suggested in the mailing list to write a temp file.

5. I can do that.

I'll make a new patch.

  Uwe

Attached is a new patch. It fixes the points 1,2, and 5 of the above list.

Created attachment 59772 [details] [review]
Patch to update paradox plugin

This should fix the points 1,2, and 5 of the problems-list.

According to http://linux.com.hk/penguin/man/3/PX_open_gsf.html
there is a PX_open_gsf  could we request a PX_create_gsf to go with it ?

PX_open_gsf() has been implemented when I wrote the first version of the gnumeric plugin. It requires GsfInput for reading the file. I may not know gsf good enough but I don't think one can write into it as well. I could implement a PX_create_gsf() function in pxlib, but writing a paradox database with pxlib requires reading and writing of the underlying file and that doesn't seem to be possible with gsf.

If the temp file is such a bad idea, I could try to find a way within pxlib to create a database without reading the database at the same time. This may work if the records are written sequencely, but I have to check first and I actually don't like that idea to much.

  Uwe

Is there anything I can do to speed up the closing of this bug?

From the gnumeric perspective we're always going to be generating the entire db on export which should be possible with a GsfOutput.  At this stage of the release cycle I'd prefer to do the right thing rather than using a tmpfile workaround.  How hard would it be to write a create_gsf ?  It's not impossible to extend GsfOutput but it would take some significant work.

Hi Uwe,

any comments on Jody's last question?

Regarding #3, the text exporter asks the user for an encoding but it is not a plugin type of exporter. The latex export  allows utf encoding to be chosen bu that is fetermine through a preference setting.

The initial problem when writing the file is still not fixed. The library pxlib has to be extended with a function which sequentially writes the records into the output file. I won't be able to do that within the next weeks and I cannot
forsee when I find time, though I would like to see write support for paradox files in gnumeric. I'll keep it on my todo list.

Regarding the encoding. paradox databases have a field which stores the encoding, but it is ment for DOS code pages. I have to check in how far code pages have
equivalents in todays commonly used encodings. Saving utf8 shouldn't be in
principal a problem but those files are not compatible with the world outside
of gnumeric.

  Uwe

This has sat around far too long.  We're clearly not going to get an update to pxlib to do this cleanly and it is pointless to drop functionality for purely pedantic code purity issues.  I'll update the patch and merge for 1.8.2.