My post Why does Corel Draw Graphics Suite X5 feel more like beta software? explains everything im having an issue with X5. In an effort to log the issues with this software, Im asking that if your an X5 User and are having file corruption, crashes, freezes and other such fun stuff happening to you killing your time and money while in Draw or Photopaint, please post it here.
In order to keep it all clean and easy for someone at Corel to follow, please only list issues for X5 and not turn it into a discussion out of topic.
Please, there is no need to try to defend Corel here as Iv used Corel since version 4 (not X4), so thats a long time using it.
Hello,
I have got some problem with Corel Draw X5 Versions.When i type "Divehi", "Farsi", "Arabic", "Hebrew" using the windows default language(using language bar) with fonts it seems to be going left to right, but in x5 if i write on a text box it seems to be okay. but normally we cant write, because "Divehi", "Farsi", "Arabic", "Hebrew" these languages are written from right to left.
Maybe there is a Unicode Barrier in x5 that has to braked so that languages like yours and mine will be typed on CorelDraw. i use "fasyha thaana word processor" application named "Friend" wich enables language to be written smoothly in earlier versions but this aplication is not compatible with x5.
in Draw:
I was making a pretty basic diagram, used the star tool... I changed the colour of the fill and it crashed.
The message box just says "CorelDRAW(R) has stopped working Windows is checking for a solution to the problem..."
... no error code or anything (that may have been helpful), just about an hour of work gone.
The colour pickers are still not fixed in Draw or PP... eg. the 3D cube pickers still don't allow you to drag your mouse around to pick a colour, and the selection can go outside the cube colour area on the right side.
Might just have been an anomaly that time. Is it repeatable?
In the meantime while you're searching for a solution, save more often and using incremental filenames (eg: <filename>1, <filename>2, ...) so you don't lose more work than you would want to have to do over again in the event of any glitch... including power glitches, OS glitches, Application Program glitches.
the 'dd'
Not to sound like a jacka$$, but in programming, there shouldn't be any anomalies (sounds like something data would say on StarTrek).
Anyways.... I redid the diagram but it didn't crash, so without repeating it a thousand times, I'd say it's not entirely repeatable.
I forgot to note that when I was picking the colour, I was using the CMYK Hue Based picker, and I noticed that when I dragged the mouse around to pick another shade of whatever hue, there are 2 boxes that flicker... one where your mouse is during the drag and one where it used to be... and the colour that is 'picked' flickers between the old and the new as you drag around. This is a bug and (thinking back) I strongly guess is the cause of the crash.
To fix the code, when there is a mouse drag event in the colour picker area... only pick the current colour from where the mouse is... not from where it was... that's the old colour and shouldn't be changed either (in that colour rectangle... it's the upper one..
ANd... another bug... sometimes the colour box doesn't refresh... so sometimes it's showing both the old and new even *after* you've released the mouse... *but* sometimes it's just a solid colour - indicating that both the old and new have been changed to the new colour. Fixing this is just a simple matter of debugging the mouse events for down/up/ and dragging. This should be extremely simple to fix... and may (?) prevent crashes.
The pseudocode works like this... when mouse up and position is inside the colour picker area, save the new and old colour to the colour indicated by the mouse's current position. ***done*** You guys need to fire some of the coders because this is really basic level logic. If this is the cause of the crash, you have other problems in the code too. To test it, make a tiny piece of code (a thread so the rest of the program can still run) that rapidly changes the colours as the user does various whatevers... and see if and when it crashes. Beta testers and the public who buy your efficient, tight, professional level, *other super awesome advertising adjectives here* product are *not* the ones who should be finding and deducing these problems. Roar!
'dd'... Thank-you for the suggestions, however, these kinds of problems are not power, OS, or application glitches... it's definitely a bug (or multiple bugs?).
Making multiple backups is a great idea. In fact, from years of using Corel I have a nervous Ctrl-S twitch in every program I use (even IE, Word, Excel, PPt, etc.) because of the occasional crashing in Corel Draw... however X5 is really really bad. I don't always have time - nor do I think I should have to make multiple backups for a simple diagram. I do appreciate the help, but I'm too pig-headed to think I should have to worry about making a backup every 10? minutes. The darned program shouldn't crash... period. ... such a simple diagram... it's no where near as complicated as what most of you are probably doing. Here's the thing... ***when the code is written*** it needs to be tested everywhichway... not versions later... and not after it's sold.
Damn it I just found another bug... sometimes when the mouse is released, the colour chosen isn't at the spot you released. There wasn't even a mouse drag event. ONLY A MOUSE UP. Maybe this has something to do with the docker position problem. Like the mouse up position is somehow getting messed up when you're trying to figure out where the colour docker is.
Maybe these problems are related to me having a two monitor setup, but while that makes some sense (eg. the docker positioning problems I've pointed out), it doesn't make sense for the vertical part of the wrong mouse up position.
Here's a screenshot showing the old and new colours sometimes the same and sometimes not in the square that's just above the cmyk hue picking area... the screenshot on the right actually also is a bug because I clicked about 10 pixels above and to the right of where the box and colour actually took the final colour from (I was trying to get close to the colour in the first screenshot). These problems are reproducible. Try it (please). Am I the only one who's seeing this?
In PP:
I openned a png file and I want to edit it... I go over to pick the colour from the main colour picking area, double click the foreground square
I pick light green and click okay.
The colour shown in the box is now a dark dark grey
I try again, by double clicking the foreground square... pick light green and when I click okay, it comes up as orange! It's so weird.
I shut down PP
copy the image into memory
open PP and then make a raster from what's in memory
... then try picking the foregroudn colour... same thing! I try for bright green and it's giving me orange.
After trying many times... this is completely reproducible for some reason.
I've tried it with the colour picking dialog box in different places and it seems to want to give me orange instead of green. Why? FTLOG why?
I decided a week ago (?) to stop using the colour docker because it didn't correctly synchronize with the actual colour that was in the menu area... but I open the colour docker and try picking green this way... partial sucess.
Here's a screenshot... again, for some messed up reason, the colour in the menu area is totally wrong, but the docker is correctly showing green. After some messing around it seems that as I drag the mouse around the green in the docker is orange or dark grey in the menu area.
Maybe it's time to reinstall the software.
I check out the colour settings and turn on warn on missing colour profile and the next time I open the document it catches it... but why can I still pick a colour in the docker that's not the same as in the menu.
Also, after adopting sRGB for the colour profile, it still doesn't allow me to pick properly.
[fix?} ---- I save as a jpg, open, no colour profile, I use sRGB... AND... wait for it... it works.
Why didn't this adopting sRGB work with the png file?... but it does with the jpg. Both are compressed file formats and presumably both can have a colour profile embedded.
Can somebody tell me if this is a bug cause it really seems like it. The part about the docker working and the menu being messed up is definitely a bug right?
I feel like PP and Draw are a secret portal to the Twilight Zone. Du nu nu nu. Du nu nu nu.
sorry, I tried several times and can't reproduce this problem... btw I remember that's happened to me some years ago (with X3, I guess)
Ariel said:can't reproduce this problem
I also haven't had it happen much... maybe about 7 times since I got X5.
Like many of the bugs, I don't see any particular reason or thing that I've done any different than usual. I wish I could say the problem is reproducible by doing XYZ, but sometimes there's nothing strange beforehand... or at least nothing that I can see. For instance, that crash bug where I was changing the colour of a star... aside from the colour flicker, there wasn't anything else weird about it. Obviously I've changed the colours of tons of stuff and I can't remember Draw crashing because of it. It's just a 1 in a million chance that some particular events happen.
I don't have anything weird running in the background... maybe a webpage or something, but nothing like streaming video or anyhting that might mess up the memory or be taxing the computer in any way. I wish I could give more details to help figure out the problems.
Because some of these problems seem so sporadic, I think the best way, and quite possibly the *only* way, to figure out how some of these weird problems happen is for the coders to write some test scripts that make the program do typical things (sometimes slowly and sometimes quick) and just run them continuously until certain known problems happen... in this case the colour in the menu isn't the same as the colour in the docker. They're probably already doing something like this already.