PageFrame SpecialEffect Property

[Scott24x7]

Hi All,
I'm struggling with something that seems otherwise simple, but I can't figure it out.
I have tried both with my sub-classed PageFrame and the base PageFrame class, there is a property called Special Effect, which is set value 0, and says "0 - Raised (Default)". But this property in the designer both as base class and sub-class this property is italic, and I can't change it. (I want the 2 "Flat" value).
I tried setting this at runtime instead in the object's init:

This.SpecialEffect = 2

But I then get an error saying the property is "Read-Only".

Is there any way to change this property? Am I missing something stupid?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[vernpace]

The Special Effect property is available only if the Tabs property is set to .F.

 

[Scott24x7]

Thanks vernpace, but now... as you might guess, that means there are no tabs. I'm essentially trying to replicate the current UI thinking with a "flat" layout. So when I turn tabs off, I notice in the page frames, the pages are still there, but the tabs are gone. So does that mean to "replicate" the behavior you have to set up your own "Fake tabs" to control movement between pages then, or does someone have some other clever way of doing this?
Or should I just wait it out another 20 years until the 3D style is back in effect again.
Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

The reason for the behaviour you are seeing is that - for reasons which we can only guess - it's not possible for the actual tabs to be flat. They need to be raised in order that you can see that one row is in front of another, and so that the selected tab looks obviously selected. I know it would have been possible to design the whole thing differently, but that's how they chose to do it.

If you really want a flat look, then you will have to create your own controls to simulate the tabs. But that's not particularly difficult, and opens the door to other effects that might not otherwise be possible, such as different colour combinations for the tabs.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The normal look of a page frame already is flat - in comparison with the looks it had on NT and XP. Yes, there is that border color, but it's not really the typical 3d look we had, flat command buttons have the same border. So in the end, the flat OS theme styling already is happening. Turn off Themes for the page frame and you'll see the difference to the legacy styling VFP does itself.

If you want to have yet a more flat look, you have to face the question Mike raises, how do you see which one is the active tab? I would let this go and stay with the way it is. But you are you.

Bye, Olaf.

 

[Jockey4]

Scott,

If you are looking for a flatstyle tab, I suggest you also explore the class of Bernard Bout: OneNoteTab

http://weblogs.foxite.com/bernardbout/2006/06/07/recreating-onenotetabs-in-vfp9/

The active page is unmistakenly shown by the background colour and the missing bottomline of the tab. Whole thing looks like an actual tabpage in your boxfile. Very nice.

Regards,

Jockey4

 

[Scott24x7]

Olaf,
Interesting point. So I checked my setting in the base class, and I already had Themes = .F. so I turned it on, and yeah, that was kind of worse.
Jockey4,
Thanks for pointing at this. I also looked at the VFPX "Ribbon" style on Codeplex/Github but it seemed to be really flaky, and the "color" differentiator isn't quite what I'm looking for.
Mike,
I think your suggestion is the way to go, and after I thought about it a bit, as you mention, it's not as hard to implement as it seems on the surface, and I'm kind of heading down a track on that now.

My thanks to you all, as this was the kind of discussion I was hoping for, where there would be some options, and I could make some decisions about what to do from there.
If you look at Word, Excl, (Office of current flavors), they are following an interesting, and reasonably intuitive flat style. The leading "File" tab is always color themed to the application, but then the rest of the tabs are white/background matching. There is a flat line that runs under all of them, and only the "selected" tab has a box around it. The very tricky thing here to do is set them all as borderless, then only turn border on for the one that is selected, AND... put a line across the bottom that is in front of the bottom line of all the buttons. This way, you can make it appear the same as the "background" color, while looking like it outlines the rest, simply by sending the button to back. I'm using a container with a label in it, and the activate event sets the active page in the Pageframe (which is the "ribbon" pageframe). Now I just use the pageframe/pages with a height of 125pixels, and can fill each tab with icon "buttons" (which are also containers with image and text) so I can mimic the button look and feel, and I've sub-classed these Ribbon Button types, so it's easy to do. I was just surprised at the pageframe behavior. It seemed like that property would do what I wanted, but it doesn't. Still thanks to all for options, and I'm pretty satisfied with how it's working so far (though I suspect it will be another week or so before I get it all working as desired). But yes, there are a lot of good options here. To hide the ribbon too works just by collapsing its size until it reaches 0 and then expanding it back with the ^ (reversed icon) button.

I'm excited by this actually! One of the feedback I got from my friends on our application a couple of months ago was "1990 called and they want their interface back". It was a bit of an "ouch" moment. So I've been trying to figure out how to give it a more modern feel since then. This also dragged us back from our plan to move it to C# since we thought we'd get all the modernization from that, but we were very surprised to find it's inheritance was a step back to 1985. We we've changed our position now, and this is a big piece of the puzzle. My thanks to you all.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

One other question...
Does anyone have any view on simply making the "Main" form (which I usually have blank and it serves as the "container" for the MDI forms that appear within it), as simply embedding the ribbon bar within this form? (I would normally setup something like:

IF NOT glQUITAPP
	DO MAINMENU.MPR
	DO MENUINFO
	DO FORM MAIN
	DO FORM SPLASH
	DO FORM LOGIN
	READ EVENTS
ENDIF

But it occurs to me if I just allocate 125 pixels at the top of the MAIN.SCX I can control all the options there (it is a headerless window), and then I can move windows inside relative to the ribbon if it is open or closed at the time the ribbon is expanded or contracted.
Is this a dumb idea?



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott, I might have missed what you said earlier about the ribbon, but the way I handle this it to make the ribbon a toolbar. You create it as a class, then instantiate it with CREATEOBJECT() and dock it to the top of the screen. I also add code to prevent it being un-docked, but that't just my preference.

Sorry if this doesn't answer your question. I haven't followed this thread in detail.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Hi Mike,
I understand the concept, but I always found the toolbars to be a bit restricted by the "thoughts of the day". Maybe that's because I'm remembering defaults, but I remember specifically years ago not going down the toolbar path. I'm shooting for something that looks truly native, even if it isn't. So my idea was to use the MAIN form as an MDI which has the ribbon as fundamentally a pageframe sat just below a series of flat text buttons (which are just containers with labels in them, which execute control code to flip the pages, and change the "appearance" around them). I'm still working on it, but the behaviour so far, and the look and feel is pretty identical to that of Office 2013/2016 now. At least for the topline. I'm planning to sort of "lazy" it when it comes to the ribbon "close" if someone wants to get it out of the way, it's just going to move the current windows(s) up in the form the distance that the ribbon takes (125 pixels).
My expectation is most will leave the ribbon Open all the time anyway...

My other thought was that, in any future applications, this "MAIN" form actually be comes the basis, and then it's simple enough to just customize the ribbons, as all the rest of the menu behaviors will be the same. I could even make it a baseform...

I'll put up a screenshot if you like once I get one of them reasonably populated. Day or two maybe.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott, I'm happy to explore this further with you, but in the meantime can I pick up what you said about toolbars being a bit restrictive.

I agree with that. They also sometimes exhibit weird behaviour, and generally make it difficult to position controls exactly how you want them.

However, there is an easy way to tame a toolbar. Simply drop a container into it. Then drop whatever other controls you want into the container. That way, you will have full control over the positioning of the controls, and the erratic behaviour will disappear (well, most of it will).

You might not want to rethink your whole pageframe idea on the basis of what I am saying here, but don't write off toolbars completely. Some years ago I created a toolbar class that closely mimics the ribbon in Microsoft Office. It contained a container, which in turn contained a pageframe (with Tabs set to .F. and fancy labels to simulate the tabs), which in turn contained buttons and other controls. It worked well and I have used it several times since them. (I published the code in FoxPro Advisor, but alas it went down when that particular ship sank.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I actually do assume ribbons are rather part of some form than a docked toolbar, so I second your thought of design, Scott. If you have a ribbon, as complex as it may be, you could easily switch between pages of a pageframe you set to have no tabs at all. Then clip the borders of the main pages area by making the pageframe 2 pixels wider and higher than the form area is, and you get rid of the look you don't like. Your ribbon surely will be based on come container, you can make that opaque or set a background image, so it covers the pageframe top border, when you send the pageframe to the back in z-order.

Since the ribbon controls which page becomes active, there is no need for the tabs, is there? If you said that earlier, it would have been my first suggestion.

Also collapsing the ribbon, you can make the pageframe.top=-1 or -2 and higher it's height and are good with a borderless pageframe. Clipping is as easy as that, you can a) use negative top and left positions and b) set width and height 1-2 pixels higher than the area to cover.

Bye, Olaf.

 

[Scott24x7]

Mike,
A very interesting idea. I have used containers extensively so far in the implementation of this, and in fact I've basically replaced all VFP command buttons with new "modern button" classes as I've dubbed them. I don't have a commandbase anywhere now that I can think of... (Maybe one). So that idea isn't foreign to me at all. I'm kind of surprised that my idea is so simple... I've seen a few attempt to implement the "Ribbon", and looked as the ThemedControls in VFPX/CodePlex/Github but it was a real mess. I don't know if maybe other people don't use a visible main form maybe? Perhaps that's why this is working for me, and I'm suddenly loving the freedom of the headerless pageframe (considering it struck me so odd before, it's kind of an interesting "ah ha" moment).

I will come back to toolbar, I have a couple of places where I think it makes complete sense. So your idea there may make it worth it for another interface feature I'm considering.
It's funny, in more than 25 years of Fox (of some flavour), I never thought I'd see the day where there was no "MAINMENU.MPR". It actually simplifies things in ways I hadn't even thought about until now, particularly around my "reference" section and how much easier it will be to dynamically build that in the future. And I can add file type image to it as well, which will also be interesting.

I'm very excited by the prospect of this.
So far, I only have one thing that is annoying me, but I think I will find an easy enough fix to that. (My container borders aren't going away when the button focus shifts, despite setting their line size to 0).



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott, I'm glad I haven't persuaded you to use my idea of a toolbar / ribbon class. Now that I have read more of this thread, your own ideas look more interesting. In fact, I did a vaguely similar interface not long ago, where the application had four main modules, and each was contained within its own pageframe page, with four big "buttons" (actually labels with fancy borders) to switch between them.

As for not using MainMenu.MPR, I'm with you on that too. I haven't used it for years. The only menus I create nowadays are context menus (responding to a right-click) or small menus that drop down when the user clicks on a certain kind of button.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads