[XXCloneMan]

I’m against adding silly features that can easily done otherwise.

A good design in tools come from the versatiilty of primitive functions that can be combined to build powerful combinations. Having zillions of specialized features is really a bad idea.

I’m voting NO.

[XXCloneMan]

Yes. It happened again (I’m still looking at it as I write this). This always seems to happen very late at night (now, it’s 2:38 am). An interesting thing is that
I opened a fresh EmEditor while the misbehaving EmEditor window is still there, side-by-side (as Microsoft says “sxs” :-)

It is quite interesting that grabbing a text file from somewhere (usually originates at a display of TotalCommander — one of my favorite tools, but I also tried to grab a file in Windows explorer display for the same result) and then drag it over the newly opened EmEditor’s area that shows “drop-accepted” cursor and then continue fly over to the older EmEditor’s area and the cursor changes to the “drop-disallowed” shape. It reminds me of an airliner fly over a friendly country that welcomes you and then go over a hostile airspace that does not cooperate.

Furthermore, there is another interesting aspect of this.

It seems there are three types of area in EmEditor’s display area.

1) Top area (TitleBar, MenuBar, Toolbar and the tabarea)
2) Projects pane (I usually keep it at the left hand side)
3) The main text-editing area

When I drag a file over a good EmEditor display,
The mouse cursor always remains the “drop-accepted” shape and I can drop it at Area 1 and Area 3 that starts the editing session. But, when drop it in Area 2, depending on where to drop, it behaves differently (according to the rule that governs the Projects pane behavior which is OK).

Now, when I try the same thing over a misbehaving Emeditor’s display area, The top section (Area 1) shows the “drop-accepted” image — but when I drop the file there, nothing seems to happen without any error message (a black hole). Then, of course, Area 2 and Area 3 of misbehaving EmEditor give me the “drop-disallowed” cursor and obviously, nothing happens when I drop it. That is, whether the mouse cursor shows drop-accepted or drop-disaallowed, the effects are the same — no discernible action takes place.

Anyway, right now, I’m looking at a total of four EmEditor displays. Two of them are “misbehaviing” with the “drop-disallowed” cursor display. I sometimes open with the “-sp” switch and sometimes without. When I open a new instance of EmEditor, the new one seem to behave well.
…Wait. I just found something different. The problem seems to have gone while I was experimenting (as I have been wriing this report (inside the Forum section here).
Now, all of the EmEditor displays behaves well and I don’t have any of them that gives the “drop-disallowed” cursor.
So, my experiment tonight ends right now. (It’s 3:32 am and I’m going to bed — strange things happen to old men at very late night). Very spooky.

One more thing: Tonight, I did not play with the Project pane very much. I was mostly doing my own work (a lot of activities with several tabs open and a few separate EmEditor displays all over the two-monitor configurations— I always need more desktop!!!

Good night…

[XXCloneMan]

Today, I cannot observe the same “disallowed-drop” behavior by EmEditor on the same machine (Win7 Ultimate x86). So, Yutaka’s suggestion of restarting Windows seemed to have eliminated the problem.

But, if I remember correctly, I did reboot the system at least once and saw the problem persisting before I made the report. I had to make some extra efforts to prepare the illustration image (http://xxclone.com/img/dragdrop.png) to explain what I saw.

While it is easy to dismiss this episode as a semi “random” behavior of an unstable machine, the computer happens to be a very stable one which seldom goes to the blue screen. So, before I forget this story, let me document what was somewhat different from my routine EmEditor operations.

In retrospect, I was doing something that I did not do before. That is, before I observed the strange “disallowed-drop” behavior, for the first time, I started to use the the “Projects” pane in a new (to me) way. That is, until yesterday, I always used the Visual Studio (VS2010) solution file as the starting point.

Yesterday, for the first time, I started to use the “Project” scheme as opposed to the “Solution” scheme. Then, I realized it is more suitable for me to create my own set of files that are relevant to a given version of my “project”. Actually, I was delighted to discover EmEditor’s “Project” scheme (.eeproj in addition to the .eesln) which was new to me yesterday. Before I started to notice the “disallowed-drop” behavior, I was playing with the feature that relates to the .eeproj file (adding, removing the member files) for several hours as part of my work.

So, for now, let me report that the strange observation was noticed after considerable manipulation of the Project pane’s contents while doing my own editing session. Once I noticed the “disallowed-drop”, it did no go away, not even a reboot.

What I’m saying is that this may never surface again. But, I have a hunch that it may be related to the way EmEditor handles the .eeproj (or .eesln) feature.

Thank you for your attention. If I observe something more, I will make another report in this thread.

[XXCloneMan]

8-) Thanks for the pointer.

Good tools never impose the designer’s idea to the rest of
the world. Every little (neat) feature like this should
be accompanied by a mechanism to disable it just in case
the intent of the feature does not fit the occasion.

Little features like this collectively make EmEditor
a GREAT product.

[Author]

Posts