if you save text use text mode on the device: if(!file.open(QIODevice::ReadOnly | QIODevice::Text)) and if (!file.open(QIODevice::WriteOnly | QIODevice::Text)) everything else comes for free
I thought the whole point of his question is precisely that he wants to produce text files which are not native to the OS, specifically he wants Windows \r\n regardless of whether his app is running under Win or Linux. That was why I was saying don't use endl etc., and of course you mustn't use QIODevice::Text. Maybe I misunderstood... :)
Can you try if specifying an absolute path fixes the problem? My guess is that it's a working directory problem.
Change "test.wav" into something like QDir::tempPath() + "/test.wav" in both createAudioRecorder and endRecordAudio
You got a number of different possibilities suggested. Possibly you are overwhelmed by the different things. Sometimes it is hard for the people answering to know where the real problem was/is.
I am not sure now if this might be too detailed for you. Anyway I move forward.
I would suggest, if you have not done yet, The example from QFile as also listed by @jsulm and play a bit around. Just change the file name to somthing you need. E.g.
That is a possibility to specify a complete (absolute) file name.
If you are a beginner, I was in that stage before as all the others, there might be a problem with the not existing folder name, if your file not created. There is QDir::mkPath, which is slightly different from mkDir. It may help you in code to ensure that you actually can create the file.
The other thing driving me personally nuts is the stupid folder separator for windows, which is a back slash '\'. However, in the mean time you can easily substitute with a forward slash also for most things in Windows (especially Qt). This also part of some of the suggestions.
If you have difficulties sometimes it helps for others to post a short section of code and the error message.
I have no time to dedicate close to a day to implement and test a method to copy files little by little (although there have to be loads of code parts already implemented I'm sure). By the moment, If the user is copying a large list of files and wants to interrupt the process, the process will finish when it finishes to copy the current file at that moment, and will erase the previous files. If the current file is huge, the user is going to wait until the end of the copy.
We know now the behaviour of the Qt copy process, so in the future if it is a problem for somebody, we will have to implement the buffer...
I know there is a "seek" function in C++, however any examples or snippets on how to use it in QT would be helpful.
Seek makes sense only for binary files (it operates in multiples of a byte), it has no notion of text, characters or lines, you can't use it. Consider what should happen if the text is encoded in an extensible format with changing character size (in bytes) as UTF-8 is, what do you seek then?
The only reliable way I know of is simply to copy the file line by line, but just substitute the line you want to change.
By the way, you possibly could use QSettings to store that data instead of maintaining your own text format.
my app wasn't able to create an empty file due, for example, to insufficient permissions: shall I call file.close() anyway?
No you're not required to.
my app was able to create an empty file: shall I call file.close()
Again, you're not required to. You can call it if you wish, but by default the QFile instance will close the file when it goes out of scope. Moreover calling close() on an unopened file is permitted, but it does nothing.
The I want to add some text to the file, but I do not want to interact with it here: I pass the file name to a function which is taking care of it.
Don't reopen the file on each write, it's a somewhat heavy operation. Have a member variable, open it once and write as much as you'd like.
Now, because of all the previous checks, I shouldn't have to check if file exists or if I can open it, right?
Wrong. No one is guaranteeing you that the file exists. On windows a file will (usually) be locked when opened, but on Linux the user can delete it even while you're writing onto it. So don't skip the checks. Also as I mentioned above, don't reopen the file on each write.
Such a strong word ... it depends on the advisory locking mechanism used and most linux-es will support more than one. As duly noted in the documentation it's only guaranteed to work if the same scheme is used across all processes:
Serialization is only guaranteed if all processes that access the shared resource use QLockFile, with the same file path.
What I suggested is not compression per se, but a way to encode (meaning represent) base pair data more efficiently. As I noted, this is no way a complete solution, but I think it should give you a starting point. Since adenine is complementary to thymine the first could be encoded as a bit sequence 00 and the other as 11, while cytosine and guanine could be encoded as 01 and 10 respectively. This way you can get the complementary base by only inverting bits. Suppose you have encoded half the strain of DNA, then the complementary strain you get simply by inverting all the bits. Since the base data is only 2 bits fixed size you can use offsets to calculate where that data is exactly located in a long base pair sequence. Suppose you have a sequence of alleles and you know that some gene contains 3 alleles and starts with the 35th allele of the base-pair sequence, then you can access the gene sequence very easily. The gene should start at (35 - 1) * 3 = 102th base pair (or 102 * 2 = 204th bit) and the size is simply 9 base pairs or 18 bits. I just hope my biology is not failing me with the calculations. So if you had the whole sequence mapped in a binary file, to read up the gene you seek out the correct position directly by those offsets:
; //< You know the drill with handling errors
file.seek(25); //< Go to the 25-th byte (200th bit)
QByteArray geneSequenceData = file.read(3); //< Read 3 bytes (up to bit 224)
// So in the byte array we've read we have the gene we're interested in, and it starts at the 4-th bit and ends at bit 22
// The total number of bits read is 24
The whole point of having a structured binary file is to be able to seek around it without actually reading things. Obviously my example is pretty superficial and it's much better to have special class that represent a base pair sequence, class representing gene offsets and other data you might want to handle. Additionally, you probably'd need some meta-information written in that file (offsets of sequences, genes or other things) so you could locate what you need. This is not possible with text files, especially in a platform independent fashion. Moreover a sequence of 4 base pairs you encode in 4 bytes when you use text files, with the proposed encoding scheme you only need a single byte!
BUT it's not truncating the old content so the new content have to be bigger than the old one. If your second content could be smaller, just take the approach with a second file...
Why don't you just append it to the end of the file?
Just for an iteration the code reads line by line. As long as the search text is found, it will provide the remainder of the line. There is real dependency to the content as long as it is displayble (probably also some non-displayable characters). There are some special characters marking the end of lines (line feed (LF) and carriage return (CR) are those at least).
@Wieland OK... So, you're replacing all the next lines in the string list to spaces and then splitting the strings by spaces. That's pretty neat. Thank you very much. This solution works perfectly for me. I upvoted all your answers. Thank you, Wieland.
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.