Building Ribbon Functionality in Application 2

[Scott24x7]

Hi All (And Mike),
I decided to start a new thread since the other was about a pageframe property, this is gone down the path of really creating based on a different idea, which splintered from that discussion.

So I have encountered one weird issue. Originally I put a container with just a label in it, but I want to "mimic" the current Office style ribbon bar. (I find it does look quite good). And the way they "highlight" the active tab is by drawing a sort of 3 line frame around it (left, top, right). I initially thought I would just turn the border property on the container to width = 1, and when I lost focus to width = 0, but when I leave the object, (even when lost focus calls for a refresh) the container keeps it's boarder. Am I doing this the wrong way?

I tried a second method, putting an actual box in the container, and a "line" at the bottom to mimic the state of the bottom of the tab, where I set the color property either equal to the form background property (when the container/tab is selected), and to the border color of the pageframe when it's not selected. Then set the visible property of the box to either .T. or .F. depending on got or lost focus, but the box persists once the container has been clicked on.

It seems the refresh clause shouldn't need to be called when the lostfocus has the visibility property changing from True to False...

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

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

 

[Scott24x7]

I did... I said they are 4K. That resolution is 3840 x 2160
There are 4 of them in this configuration as well, if that makes a difference. So the total desktop screen resolution availble to one application is 7,680 wide x 4320.
I'm keeping the app though, running in the "main display".
The 2048 was based entirely on how much of the width I wanted the application to take up.
I think I see your point about _SCREEN though, so instead set the top level form's height/width properties and it should be ok.


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

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

 

[Olaf Doschke]

Of course, you set your top-level forms height and width, your form is not _SCREEN just because it is top-level.

In the Init() you can use THIS or THISFORM. (In any form method THIS=THISFORM). _SCREEN is always a separate object, it always exists, but always is not your form. Let me do this for you: Duh. This really hurts.

Bye, Olaf.

 

[Scott24x7]

LOL. Thanks Olaf, I did not understand this nuance of the _SCREEN object, and explains why I never touched it before as well.
Now I get it. I made the fix in the INIT in the top level form already, and it's all good now. I can see you could probably set _SCREEN.Height = 0 and .Width = 0 and effectively make it invisible, and give it a reference to all other windows of 0,0.

Don't know if that matters much if you have SCREEN = OFF in the Config.FPW anyway.
This Ribbon has been interesting. It's caused me to make a lot of stuff better than it was before, because I hadn't approached it this way previously. Some subtleties involved in dropping MAINMENU.MPR.
It's progressed pretty fast though, and aside from the self-inflicted annoyances, it's gone well. I've tried to model as much behavior in the ribbon as possible from Office. I think the fun part will come when I have to build the "FILE" menu, which in current Office flavor takes over the whole window. So that should be interesting.


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

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

 

[Olaf Doschke]

Well, why care too much about an object you don't use anyway. SCREEN=OFF means no more and no less than setting _SCREEN.Visible = .T., therefore this VFP "system" form never gets in your way. The reason SCREEN=
OFF is better than _SCREEN.Visible = .F. is that the _SCREEN then really never is visible. You have to know even your first line of code runs after _SCREEN is made visible in the normal case, indeed many things run before your first main.prg or another main file of your project becomes active. And without SCREEN=OFF that means a flicker of _SCREEN shortly visible.

And finally also notice SCREEN=OFF does nto mean _SCREEN is not generated. It will always be there, no matter if you need and use it or not. It doesn't matter, so don't care about _SCREEN at all. Some frameworks you use may use it as publicly available object you can add objects, too. Fpor example gdiplusx adds itself to _SCREEN. So you also better not try to release it or get rid of it in any way.

Bye, Olaf.

 

[Scott24x7]

For better or worse, I have opted not to use any of the frameworks. So I have focused on building my own instead. Yes, it takes a little longer, but has the benefit of knowing your objects, your control, how they interact. Not saddled with unknown behavior that is obscured by someone else's stuff. I can see why some would go that route, but now today, especially with tool makers essentially vanishing, I'm not stuck with an unmaintainable blob either.
So, I do it the hard way instead, but I think in the long run, it is better. That was even more so confirmed to me when I started looking at Ribbon bar options... they just didn't do what I wanted them to do, they were all "Welcome to 2007 and WindowsXP".


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

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

 

[Olaf Doschke]

Well, gdiplusx is not a framework, but a library, and I think you already use it additonal to foxypreviewer. You know better, but anyway, you shouldn't care about _SCREEN, SCREEN=OFF is all you needed to get it out of the way and have your own top-level form. And that's it. You only would have reasons to learn more about it and act on it, if you'd use it.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Nope, we're not (yet) using gdiplusx or foxypreviewer (We tinkered with it when we were looking at FoxInCloud, but we've since abandoned that approach as well, as it took over and made it the more "important" object, really screwed with our VFP installation, and we had to basically uninstall everything and start over. So I've constantly avoided using these kinds of "solutions" because they just conflict too much with native VFP. I treat VFP largely like I do Excel... everything as native as possible. I only use VBA in Excel when there is NO other way to do what I need otherwise. With VFP I've done the same. I even consider "Shellexec" to be an extravagance because we have to use an API call (same with moving our headerless forms). But there was no other way to do it.

In this case, I'll look for the "most native" way. I can see eventually where we might favor some function of gdiplusx, but for now, we're still full-on native wherever possible.

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

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

 

[Scott24x7]

So I found an interesting trick today to resolve the "peeping icons" issue that I had.
I noticed that if I was on a tab in the ribbon that didn't have any of the large icon container classes that I'm using, there was now icon "show through" when the pageframe is collapsed to 1 pixel. And as I go to those tabs, when they are exposed, and the frame vanishes again, the still show through.
So the interesting sneaky thing I discovered is, I added a blank page to the frame (since the tabs are set to .F. you don't get any "page x" tab). Then when the call to shrink the pageframe comes, I save the current page, then switch to the empty one, roll it up, and no icons poke through. When I click another tab, I swith to that page, open it, display the ribbon as long as they are there, and when leaving roll it up again after switching to the page with 0 controls on it.
So a little kludgy, but it gives the desired outcome, which is cool.


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

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

 

[Olaf Doschke]

You posted the solution to a problem you rather discussed in thread184-1777918.

There I proposed several solutions working with UIEnable etc., but in case of needing no tabs an empty page should have come to mind earlier. I consider it an elegant workaround. Workarounds always are a bit kludgy, but this is a much simpler solution making use of the fact you don't need to care for an additional tab and so it's much more elegant than setting all controls invisible via UIEnable event.

Bye, Olaf.

 

[Scott24x7]

Olaf,
Ah, you are right. Sorry I put this in the wrong thread. But thanks for the kudos, I thought it was interesting enough that it was worth posting back up. Maybe when I get all this working, I'll do an FAQ and how to avoid the gotchas'. I did use the UIEnable idea for something else though, so it too was worth nothing.


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

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

 

[Olaf Doschke]

I think I know what you meant to say. Thanks, and since the two related threads now are linked by the comment, that's fine for later readers, too.

Bye, Olaf.