How to allow a window to be dragged without a title bar 1

[steve4king]

I'm sure this has come up before.. but not finding any clues about this.

Using a title bar for child windows in an application is a very outdated look. However, once removed it's not possible for the user to relocate the window without stretching it around.
I expect there is a neat little hack for this.

Anyone?

Thanks,
-Stephen

 

[Mike Lewis]

Why do you think it's outdated? A form's title bar is very much part of the Windows user interface. It provides the means to drag a form around, plus it hosts the standard Close, Maximise, Minimise and other buttons. In short, it's something that users expect.

I agree that some forms don't need a title bar: perhaps a short-lived user alert, or an extended tooltip. But those aren't the kind of forms you need to drag around.

Just my humble opinion. No doubt others will disagree.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

No disagreement here.

The answer to "how do users move windows around" is "with the title bar". There's even a keyboard shortcut but it's completely bound to the application menu available in .... the title bar.

 

[Olaf Doschke]

You find what you search in News2News pages about form skinning, eg here:

http://www.news2news.com/vfp/?example=499

But take a look: They still drew a title bar.

Even MS put one of their application off from the standard: Zune Player, it has no title bar and standard border, not even Aero style. But even that window is set up to only be draggable in the upper title bar area.

Bye, Olaf.

 

[steve4king]

I guess the difference is when you don't want the application to feel like part windows as much as it's own entity.
But you make a fair point Mike. In that list of forms that may not need to be mobile: Modal forms.

If I cannot access anything else, why would I care about the arrangement? I will probably center and lock my modal form. The other I'll use Olaf's link. (thanks!)

I may be in the minority here, but we don't really want this program to look like it's an extension of windows during certain uses.
I hide the windows task bar, the _screen title bar, status bar, and border to provide a more dedicated experience in the program.

Think of a full-screen video game. It may have panels with various displays, but oftentimes they will not have title bars. You know what it is based on content or context. If it is intended to be closed it will often have a 'close' button. The title bar would interrupt an otherwise unified, fluid design. If mobile, usually they are draggable by dragging a specific area of the window/panel or the border.

In my scenario, window controls are redundant to more descriptive controls within. My form needs to be fluid and "pretty" over anything else. I don't want the user to feel like they are using a computer when they navigate on their touchscreen. Removing the title bar just makes more sense than creating a custom one.(Another option)

Thanks,
-Stephen

 

[Dan Freeman]

All is fair in software design, I suppose, but an inconsistent design (sometimes it will, sometimes it won't, based on content or context) will just befuddle your users. This is a fundamental design element behind the Mac and Windows OSs.

You *almost* describe a console application. That's fine if it's the only application that ever runs on that computer. But I can tell you from personal experience that when I've encountered applications that behaved that way on *MY* personal computer they weren't run more than once. They were uninstalled immediately. In case you think you're "unique" or "special", you aren't. People have done this before and failed.

Think it through carefully. If you've got a situation that justifies the behavior, by all means go for it. But be aware it's difficult to do for a reason.

 

[Koen Piller]

Hi,
to make a form without a tittle bar moving around you could make use of the form.mousedown property, move and show. How your customers to close the form without a title bar, suppose a button?
Try following code:


PUBLIC oFormVFP as Form
oFormVFP = CREATEOBJECT('MovingVFPForm')
oFormVFP.Move(50,50)
oFormVFP.Show(0)
RETURN

DEFINE CLASS MovingVFPForm as Form
TitleBar = 0

PROCEDURE MouseDown(nButton, nShift, nXCoord, nYCoord)
LOCAL lcWindow, lnLeft, lnTop
lcWindow = IIF(_screen.WindowState = 1, Thisform.Name, '')
lnLeft = This.Left - MCOL( m.lcWindow,3 )
lnTop = This.Top - MROW( m.lcWindow,3 )

DO WHILE MDOWN()
This.Move(m.lnLeft + MCOL( m.lcWindow,3 ), m.lnTop + MROW( m.lcWindow,3 ))
ENDDO
ENDPROC


ENDDEFINE

Regards,

Jockey(2)

P.S. The original code is from either Stefan Wübbe or Sergey Berezniker

 

[Mike Lewis]

Jockey,

I did think of suggesting something similar. But the difficulty is that the MouseDown will only fire in the form itself, not in any controls contained in the form. You would have to percolate the event up the containership hierarchy to be sure that it would always take effect.

Then again, that's probably not what you want, because it would interfere with the normal use of the mouse within the controls.

I guess it comes back to giving the user what they would expect. If you wanted to move a form but couldn't see a title bar, would you think of dragging the form itself?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Koen Piller]

Mike,
I Agree with you. A form without a titlebar is an unwanted thing and certainly not according to windows standards for normal forms, users expect the bar.
However I can think of a situation where this is needed, an information form e.g. popping up over your mainform in an unwanted postion. To be able to drag it aside to read underneath could be well wanted.
And that it does only work on the form itselve is true, sorry I forgot to tell.
Regards,

Jockey(2)

 

[Dan Freeman]

However I can think of a situation where this is needed, an information form e.g. popping up over your mainform in an unwanted postion. To be able to drag it aside to read underneath could be well wanted.

On the other hand, this could be an excellent argument for including a title bar so the form can be moved.

 

[Olaf Doschke]

Dan, very clever. Like a Messagebox, perhaps? LOL

In my oppinion you have a point of no titlebar, when you want to do a fullsceen application, but then you also have no need to move such a form.

Bye, Olaf.

 

[stanlyn]

I'm seeing more and more forms and windows with no title bars, which is much easier to move. You move them by clicking and holding any blank area on the form and drag. It appears that Win8 is moving in that direction as well as Visual Studio 2012 as well, just look at some of their installation screens. I expect mobile apps to change the old windows way of things, just look at a lot of java apps...

Just my 2c worth, Stanley

 

[Olaf Doschke]

You're right, stanlyn, but that's about touch display and touch interaction. When you go to the Win8 Desktop it's still the old world. And title bars are not windows exclusive. MacOS and Linux forms also have title bars on their desktops. iOS differs, but it's a different world than the desktop.

You have a totally valid point about this for a touch interface. I also see younger people coming from Smartphones wanting to implement what they are used to from them onto the desktop. It's possible now, because you can have touch displays for the desktop, too. I think of that as really the biggest nonsense I've ever experienced. I will always develop with the keyboard. And I will not hurt my back with bad sitting positions or hurt my eyes by setting up a display nearer to the keyboard, just to be able to have it in touch reach.

If you want to develop for touch, you can, there are much more ideal platforms than VFP for that, but I can understand that decision for touch enabling an old well known and used fox application. You will have new tasks in there, eg making you UI elements big enough, independant on dpi and/or device dimensions.

Bye, Olaf.

 

[Mike Lewis]

It's possible now, because you can have touch displays for the desktop, too. I think of that as really the biggest nonsense I've ever experienced

Absolutely right. A touch interface for a hand-held device is obviously right. But for the monitor of a desktop PC, it's an ergonomic disaster.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Absolutely right. A touch interface for a hand-held device is obviously right. But for the monitor of a desktop PC, it's an ergonomic disaster.

Exactly right.

When I first saw a Win8 demo, with the touchscreen bias, my first thought was "why on earth would I want to hold my arm in the air all day long?" <g>

 

[Dan Freeman]

If you want to develop for touch, you can, there are much more ideal platforms than VFP for that, but I can understand that decision for touch enabling an old well known and used fox application. You will have new tasks in there, eg making you UI elements big enough, independant on dpi and/or device dimensions.

Indeed. We did a touch screen app for a factory floor back in FPD in 1992 or so. We had to make all the controls really big for the gloved factory floor workers. (Most invisible buttons over text elements.) I would not have wanted to retrofit an existing app designed for general desktop use/input. There's just too much that needs to be re-engineered.

(On the topic of touch input: everything old is new again!)

 

[Olaf Doschke]

I once had an incidence of wanting to swipe some icon on a TFT screen, after using an iPod touch all day. But that wasn't permanent, and I didn't get the idea this would be nice to have for a desktop PC. It's perhaps okay for someone coming into an office and not sitting at the keyboard and mouse, wanting to show something and interact directly on the screen. But it's not something you would like to do as a screen worker with todays setup of display, keyboard and mouse. You would need to have this on your table instead of a keyboard. But I wouldn't want to look down on the table all day and get a stiff neck from it. It doesn't work from the ergonomic point of view, not for me.

There has to be someone at Microsoft thinking this is a good idea, not only for tablets, netbooks or notebooks, but also for desktops. I really can't get why that interface is forced to Windows users.

Bye, Olaf.

 

[Dan Freeman]

There has to be someone at Microsoft thinking this is a good idea, not only for tablets, netbooks or notebooks, but also for desktops. I really can't get why that interface is forced to Windows users.

It's Microsoft's age-old "Windows everywhere" thinking. (Personally, I don't want Windows anywhere near my refrigerator!) They've been trying to force Windows onto tablets (and everything else) for years. By contrast, Apple got it right by keeping iOS and MacOS as mostly different operating systems with different purposes.

<shrug>

It is what it is. Personally, I don't buy the "one size fits all" approach, but that's been Microsoft's philosophy since the earliest versions of Windows. (Anyone remember WinCE?)

 

[Olaf Doschke]

I read "WinCE" quite frequently in MSDN API references. But yes, it's gone.

Actually, I like the one size fit's all thought, same codebase. Mobile device specs don't differ much from desktops we had a few years or moths ago, so why need a shrinked down version of the OS? It's just the handling differs very much. They should just either hide the tiles start screen in W8 for desktops or make it usable with both fingers and mouse. Double clicking is still what we're used to, not swiping. And yes, swiping is okay for touch UX.

What I learned last weekend on a german devcon (besides many other stuff) is about this:

http://www.zdnet.com/blog/microsoft...ows-8-slide-that-everyone-wants-to-redo/10736

For Apps there still is a layer between your language of choice and the core, but the WinRT API layer is very much the same already, so this means less layers you need to cross to get at the file system, display, etc. No Browser in between Javascript and the OS. That architecture promises very performant apps. The downside is, despite this being HTML5+Javascript, it's very proprietary and not moving towards standards.

Bye, Olaf.

 

[steve4king]

I see this thread received a lot more attention after I found my solution haha. (My email must be configured incorrectly as I received no notices)

Yes, this is actually a move to make an old VFP point of sale application more touchscreen friendly.
Personally, I would not want to use a touch application on anything bigger than a cellphone. If it's too big for my thumb to reach across, I'd rather have a KB and mouse. However, there are verticals where touchscreen is/has-been in use successfully for many many years. The screen is usually mounted at an angle at belly-level so-as not to cause "gorilla syndrome".

Following the queue of the trending touch interface designers is what instigated this title bar removal.

To move the window I ended up just doing this:

mousedown

IF nButton = 1
	WITH this    			
		.originalxpos = nXCoord
		.originalypos = nYCoord           
	ENDWITH
ENDIF

mousemove

IF nButton = 1
	WITH thisform
		.Left =  .Left + (nXCoord - .originalxpos)
		.Top =  .Top + (nYCoord - .originalypos)
	ENDWITH
ENDIF

However, I did come to the same conclusion that I would have to handle the movement from the parent to keep things smooth. (works fine on any system with modern/discreet graphics.) Any lag and the cursor ends up outside of the child form which breaks the movement.
Haven't gotten around to that part yet.