-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QImageLabel Failing #152
Comments
The issue #92 can be related to this. |
Probably not. I guess what we are doing is to serialize/deserialize the Compression/Decompression is working fine. Also, I am not able to reproduce On Wed, Feb 27, 2013 at 3:43 PM, Oleg Abrosimov notifications@github.comwrote:
Regards |
The link where the problem is described: http://serverfault.com/questions/388858/how-to-fix-file-name-too-long-error-in-apache2 It seems that in a case of CacheFolder not set, the whole QImageControl architecture is broken. It can produce URL's that would be rejected by the web server. The QImageControl should be redesigned. |
Yet another instance: http://www.c-integration.com/forum/showthread.php/50-qimagelabel-not-working How about we make |
…or file name length. * It fixes issues qcubed#92 and qcubed#152 * The example of QImageLabel is changed to use CacheFolder property. * The exception is throwed if the CacheFolder is not specified and the resulting file name length exceeds the 255 limit.
One of my friends have been facing an issue with QImageLable - the trouble is that when he does not specify the CacheFolder for the lable, the image rendering fails. The reason specified in the error log is - 'filename too long'. Is there somehow we can fix this? The error log says this:
What can be the solution? I am stuck because unless you bring in the database again (and I don't want to bring that in) for this control, it may not be reliable. Otherwise, we have to make the 'CacheFolder' mandatory.
Regards
The text was updated successfully, but these errors were encountered: