I have to agree with Mark, Oliver. The cursor should indicate what will happen if I release the mouse button. It would very unfriendly to let nothing happen. That eliminates options A & C.
That was not the way it was done in OS/2, iirc. Perhaps it was true within the Workplace Shell, but that might have been because you could drag anything anywhere. I don't think that was the rule for general CUA applications. BTW, just for completeness, the cursor should not change on button down. It should take button down plus dragging outside of the local box, right? One metric I use is the "How easy is this behavior to explain to my 84 year old mother?" :-) -Chip- On 1/10/12 00:39 Mark Miesfeld said: > I'm not sure I see what the differences in the 3 approaches are. > > In all three, if, when you press the mouse button down, the thing below > is not 'draggable', then nothing happens. > > When you are dragging something, the recommended approach is to indicate > to the user that the dragged item either can be dropped and something > will happen, or it can not be dropped and if dropped nothing will > happen. If the user drops the item when it is indicated that it can be > dropped and nothing happens - then that would seem to be a bug in the > program. > > Anyhow, in ooDialog you are going to be limited to what you can produce > as a cursor. If you can produce a cursor that looks like the thing you > are dragging, then you can use that. If you can produce a cursor that > looks like the thing being dragged with a No symbol over-laid on the > picture you can use that. > > In most places where you see a picture of the item being dragged, and > always if the picture is bigger than a cursor, the drag and drop is > being implemented through COM, or the application is painting the > picture while the dragging is being done over its client window. > Painting images in ooDialog is next to impossible. Which is why you are > going to be limited to using cursors. > > -- > Mark Miesfeld > > On Mon, Jan 9, 2012 at 2:45 PM, Oliver Sims > <[email protected] > <mailto:[email protected]>> wrote: > > __ > If I build some sort of drag/drop framework for the Guide, then I > need to define how drag/drop should *look*. > I've been experimenting with my Windows system, dragging stuff > around and seeing what happens to the mouse cursor. > There seem to be three broad options: > > Approach A (Windows XP Native Drag/Drop) > - On pickup (button1 down), either nothing happens or the mouse > cursor changes to a little picture of the thing picked up. > - When it's dragged over other programs (or the screen background) > either the cursor does not change, or it changes to a no-entry sign. > - If I drop when the mouse is a little picture, then either (a) > nothing happens, or (b) the target says it can't handle it, or (c) > it accepts the drop and something changes on the target window. > - If I drop when the cursor is a no-entry, then nothing happens. > > Approach B (see sample ooDialog drag/drop program "userDlg.rex") > - On pickup, the mouse cursor changes to a no-entry sign. > - When it's dragged over other programs (or the screen background) > the cursor stays as a no-entry sign, but if it's dragged over an > ooDialog dialog that will accept a drop, then the cursor changes to > a little picture. > - If I drop when the cursor is a little picture, something happens > (assuming the ooDialog code is well-mannered). > - If I drop when the cursor is a no-entry, then nothing happens. > > Approach C (a possible alternative approach with ooDialog): > - On pickup, the mouse cursor changes to a little picture of the > thing picked up. > - When dragged over any non-ooDialog window, the cursor remains as a > little window, but if it's dragged over an ooDialog dialog that will > NOT accept a drop, then the cursor changes to a no-entry sign. > - If I drop when the cursor is a little picture, then if the target > is an ooDialog dialog that will accept a drop then something > happens. Otherwise nothing happens. > - If I drop when the cursor is a no-entry, then nothing happens. > > > Which of these options should be used (for the Guide at least)? My > own preference is, I think, Approach B. > > Any thoughts? I did check my dusty 20-year-old CUA manuals, and > while it seems to suggest approach C, I know that the context of was > the OS2 desktop (as opposed to use by applications). So not a lot of > help there... > > Thanks for any thoughts, > Oliver > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a > complex > infrastructure or vast IT resources to deliver seamless, secure > access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI > infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Oorexx-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
