§ ¶Gotta show 'em who's the boss once in a while
Photoshop Elements is one of my more favorite programs for a couple of reasons. One, I like paint programs in general. Two, it doesn't suck. Okay, you can probably point out a million ways that Photoshop could be improved (starting with using the right mouse button for alt-painting), but it's way better than other programs I've used. Paint.NET is cool, but it's missing a lot of features and it's pretty slow, and Paint Shop Pro has had a broken resampler in every version I ever tried. PSE6, on the other hand, is a lot faster and more stable, and aside from some gratuitous skinning, I find the UI hasn't changed much even from Photoshop 2.5.
There's one really irritating problem with it, though.
For some reason, Photoshop Elements 6 has a habit of getting into a state on my machine where it randomly refuses to create or open files. New File? Dialog pops up, click OK, nothing happens. Open a file? Nothing happens. Launch a PSD file? PSE6 opens, blank. The application doesn't hang, it just doesn't do what was asked. This is pretty much the worst failure state imaginable for a program, because not only does it just shrug and not do what you asked, but there isn't even any crash, error, or any other sort of feedback to indicate a possible course of corrective action. I've tried all of the usual solutions, including blowing away the preferences file and fiddling with printers in Windows, to no avail. Reinstalling from scratch didn't help, either. Nor fiddling with scratch drives, monitoring for file I/O errors with FILEMON, or killing and restarting all of the annoying background tasks that PSE6 loads. And weirdly enough, the problem will just go away for a while and come back later. It'd been behaving lately.
Until I tried to scan a document a few minutes ago, at which point it once again decided not to create, open, or scan any images.
Out of a fit of frustration, I launched WinDbg and attached it to Photoshop -- and lo and behold, it started behaving. No need to do anything. I detached the debugger, and it still behaved. I guess the mere threat was enough to put it back in line.
(Needless to say, if anyone knows of an actual solution to this problem that doesn't involve weapons of mass debugging, I'd be grateful. Incidentally, I did also find out that the suggestion to fiddle with printers in Windows isn't as dumb as it sounds, because for some bizarre reason, Photoshop loads the printer driver every time you create or open a document. Bizarre.)
I know I would surely sh** my pants if I was a buggy programm with you around, Avery :-P
Draget - 26 09 09 - 00:43
Hmm... possibly there's some sneaky race conditition in there? The debugger will have suspended the process when you attached it. Or perhaps there's a bit of code that goes like:
if (!IsDebuggerPresent() && rand() < 0.05)
On the printer drivers: my guess is it loads it to do colour correction. Certainly Corel Photo-Paint does this - it adjusts the on-screen colours using whatever ICM profile is assigned to the printer.
Torkell (link) - 26 09 09 - 01:24
Did they ever add a clone brush to Elements? My previous employer would only equip us with Elements, and this used to severely cramp my style for Photoshop roasts over email. I would have to do a cut and paste and then use the eraser, rather than just bust out the clone brush.
Trimbo (link) - 26 09 09 - 02:47
Photoshop Elements 6 does have the clone stamp brush tool. I don't know what they may have added in newer versions. The main features missing in 6 relative to full Photoshop are: 16-bit precision, actions, curves, and layer masks. Doesn't bother me much, as do almost everything with layers, the brush tool, and the smear tool.
As for the underlying cause, my bet's on either uninitialized memory or a thread race condition. Curiously, it seems to be throwing an exception of type photoshop_error at weird circumstances, like dragging a window.
Phaeron - 26 09 09 - 12:35
are you running an x64 version of Windows? I have seen weird behaviour & black painting in numerous applications due to the following bug/feature:
roo - 30 09 09 - 15:02
While recently I just came across this "Gimp", not sure it will suit your usage as I haven't try it out yet, hehe. I might try it one day when I need to draw something -.=! I was recommending it as U r developing open-source software, as I think U might have come across it too. Thanks.
boyumeow - 30 09 09 - 15:17
No, this is on XP32... and personally I would stay away from a component that used the CALLWNDPROC hook....
The last time I saw the Gimp, one of the big problems was that its keyboard shortcuts were gratuitously different from Photoshop's. I'm hardwired to Z/X/B/H/R right now. As for it being open source, well, I'm open to proprietary software whenever it works better, which it often does.
Phaeron - 30 09 09 - 16:11
As far as I know, Gimp 2.6.7 (latest stable version) uses (Z)oom, e(X)change background/foreground color, (B)ézier, (H)ide, (L)inear gradient etc.
If that's gratuitous to use a tool's initials for a shortcut, then I wonder what would be better. Moreover, ALL shortcuts in Gimp can be remapped (and actions without shortcuts can see one added). You can then map Gimp's keyboard like Photoshop's. A ready-made scheme already exists (it's quite old now, but should still work) and is available here: http://epierce.freeshell.org/gimp/gimp_p..
Now, if Adobe could map Photoshop's keys to the Gimp's...
Mitch 74 (link) - 05 10 09 - 02:12
Windows xp I have noticed is actually much more resource constrained than windows NT was, since they merged code with win98 actually. I found apps running out of GDI handles and other resources such that whole applications would not paint their screens or even just disappear without a trace or an error message. Other bizarre behavior can account for this too! To raise win xp resources...
There are a couple of XP registry entries that can raise these... Hope it helps!
See these links
To use this hotfix, you must create or modify the following registry values to specify the number of NT User handles that you want to allow. The maximum number is 18,000.
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\USERPostMessageLimit (REG_DWORD)
INSTRUCS CHANGE/ADD THESE 3 KEYS to 18k, 18k, 65k
Open the registry editor regedt32, then look for the keys,
The user process handle quota has a hard limit of 18000, thus you can increase the default from 10000 to 18000 to make it possible to create many more function windows in Windows 2000 or Windows XP.
The user post message limit is another user modifiable setting affecting applications like NeoTicker that has heavy communications among its own threads and with other applications within Windows. If you track a lot of symbols using any one of the supported ActiveX data feeds, then you can increase this number from 10000 to 18000.
But one may increase the quota for GDI objects by starting regedit and changing the default limit of 10.000 of GDI objects in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota.
This value can be set to a number between 256 and 65,536.
Greg - 05 10 09 - 13:05
Note that the point of the per-process limits is to prevent single applications from taking so many resources that other applications begin to fail. I question the need for any application to use 10K handles, because in my experience this means that either they are badly written or have a handle leak. Most applications, even complex ones like Visual Studio, don't go above around 2-3K handles, and many sit around fine at less than 1K.
Phaeron - 05 10 09 - 15:41
Not unusual behaviour for a program. I have seen that on Windows Media Center on XP, which was really doing things I don't want it to. Believe it or not, buing a box of Vista and placing it besides the monitor... and XP Media Center worked fine ever since :-)
Dinsdale - 23 11 09 - 07:43