[Solved] Basic QIODevice subclass in Qt4

[andre]

Is there a reason you set the key twice in the first example?

[giesbert]

Ups, no,

It was first in the c'tor, then the additional function.
I should add a c'Tor without the key...

Thanks for the hint.

[andre]

I hope you don't mind that I edited the wiki entry itself too :)

[giesbert]

All is fine :-)
I now changed the code and also on gitorious.

[paucoma]

Wow, Fantastic, Marvelous, Wonderful, Excellent!!
You guys Rock!
I've tried the classes out and great, I'm sure many will benefit from your brilliant contributions!

I've added a couple modifications to your SimpleCryptDevice class.
SimpleCryptDevice.h
@
// ----- construction -----
/**

• Constructor.
• Constructs a SimpleCryptDevice instance.
• The underlyingDevice needs to be set with setDevice.
• The crypt key can be set by setKey.
• @param parent parent object, see Qt documentation
  /
  SimpleCryptDevice(QObject parent=0);
  // ----- methods ----
  /**
• Sets the underlyingDevice
  /
  void setDevice(QIODevice underlyingDevice) {m_underlyingDevice = underlyingDevice;}
  /**
• Returns the last error that occurred.
  /
  int lastError() const {return m_crypto.lastError();}
  signals:
  /*
• This signal is emitted when SimpleCryptDevice writes a block of raw data to the underlying device.
  /
  void blockWritten();
  @
  SimpleCryptDevice.cpp
  @
  SimpleCryptDevice::SimpleCryptDevice(QObject parent)
  {
  }
  int SimpleCryptDevice::writeBlock(const QByteArray& bytesToWrite)
  {
  //...
  //..
  //.
  emit blockWritten();
  return realBytesWritten;
  }
  return 0;
  }
  @

Justification of modification:

• blockWritten() signal
  ** to provide feedback to a QProgressBar.
  *** I externally calculate how many blocks will be written dependent on the block size chosen
• Bare constructor
  ** to connect the signals before I define the device.
• lastError()
  ** to have access to the last error

Although the compiled code works fine, I would apreciate if you point out any error / malpractice I have done.

Thanks loads again!

[andre]

There is a potiential danger, that you have not set the underlying device before you start using the device if you take it out of the constructor. Because of the guarantee what was there before your modification, there is no check for that. Other than that, I can think of no major issues.

[giesbert]

That was exactly why the underlying device was part of the constructor. It does not make sense to reuse the SimpleCrypDevice with another base device. And also not without an underlying device.

The signal looks good. I will add it to gitorious and the wiki.

[paucoma]

Aha ok,
Thanks for the warning.

So I have restructured my code to connect the signal after getting the device parent pointer.
I have taken away the bare constructor and the setDevice method.

I have maintained the lastError() addition
@ int lastError() const {return m_crypto.lastError();} @
to be able to access the error. As m_crypto, (SimpleCrypt object) is private, there is no other way of accessing the error from a simpleCryptDevice instance otherwise, right?

[giesbert]

also correct and a good idea. What you do not capture with this, is errors of storing itself.