Lost selection between forms

[Scott24x7]

Hi All,
This is related to the RTF controls, but I think it's different enough and lost among the other thread, so I'll ask here.
I have a form that is a child form inside a top level form. The top level form has RTF font controls on it, and it's managed through BINDEVENT (though I don't think that's an issue, just some background).
When I'm in the child form, I highlight text that I want to make changes to its font. When I go to the parent form where the RTF font controls are, when I click on a control (like font name or size) the selection no longer shows selected. However, the change made (like select different font or font size), still applies to the text. When the child form gets focus again, it shows the selected text, and change applied (so long as you don't click IN the control).
What I would like at least, is keep the selection highlight shown while away from the form, until object of the form focus changes, or click elsewhere in the same control. Any ideas?
Thanks.


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 can't have the RTF text selection marking persisted because this selection is even removed if you just tab to another control than the RTF control (with RTF control I mean the Rich Textbox itself, the control for editing the text, not a control controlling some feature like font, color, etc.). When you tab back to the RTF control the selection highlight (blacked text) is back again, so it is remembered, that's also why the interaction works nonetheless, the SelStart/End is still set.

So this kind of behavior would only work if you turn your whole ribbon into a toolbar.

This reminds me of a setting we have in the FoxPro grid HighlightStyle, you can set that to 2, which means: "Enable highlighting for current row and [highlight #FCE94F]persist[/highlight] when grid is not the current active control."

I don't see such a persisting setting for the Rich Textbox Control, neither in its object properties nor in its OLE properties.

Bye, Olaf.

 

[Scott24x7]

Ok, I understand that.
Is there a way to back highlight text in RTFEdit box?
What I'm thinking then is to have Selection to, on lost focus, set the highlight color to black, so it stays "higlighted", and on get focus, turns that off... I was looking for a way to do this earlier and didn't see it in the .Sel<something> settings. But maybe I missed something?

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

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

 

[Scott24x7]

I just went to Solution to look at it again, and figure out what's happening, but I see now that it's because it's a toolbar... So maybe the answer is to convert those controls to a docked toolbar in the ribbon?
Oh wait, now I remember why I didn't make it a toolbar... it wouldn't allow me to make it an object of the toolbar or the form...

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

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

 

[Olaf Doschke]

>it wouldn't allow me to make it an object of the toolbar or the form

What do you mean with this?

I thought your reason of not using the toolbar as root of your ribbon is it's automatic layouting and rearrangement of controls you don't like the user to be able. Alone its capability to undock is unfortunate. The idea to move your tools around and have them vertical instead of horizontal, etc. may be nice for a small set of tools, but not for a ribbon.

If you mean being able to address inner toolbar controls with object references, I wonder why that should not be possible. But even if that is impossible: When you beginn to go with my suggestion and have goApp.oSettings and properties on that level to reflect the current information to share from ribbon to the rest of the application, it wouldn't matter, if you can address controls inside the ribbon, they are just the UI to influence goApp.oSettings properties and you get your info from its proeprties or bind to them.

Bye, Olaf.

 

[Scott24x7]

Hi Olaf,
Yeah, it was multiple reason, but yes you got the main point. Moving it around is problematic. I didn't want that happening. I had a version with toolbar, I tried to copy it into the ribbon at one point but I got some error (cannot add a Form/Toolbar Class to a Form/Toolbar Class). So I just passed and when to a container based solution. (This all originated from the Solution example, which RTF control had it both as container based and toolbar based, but I totally revamped it as container.


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, you can only have a toolbar, but you could put a pageframe in it and everything else in pages or containers, depending on what modularization you want.

You can autodock a toolbar, I think you could also prevent undocking, it should be ppossible to RETURN .f. or have NODEFAULT in events about the undpocking. Thereby overcoming the layout problems.

Bye, Olaf.

 

[Mike Lewis]

Scott,

For what it's worth, I use a toolbar for my own ribbon class. To prevent it from being un-docked by the user, I have this in the Init:

[tt]this.Dock(0)
this.Movable = .F.[/tt]

and a NODEFAULT in the DbleClick. Between them, they neatly solve the problem.

As for as the other toolbar problems are concerned, many of them can be overcome by putting all the controls in a Container (as I think I've mentioned before).

Having said that, I would think it would be a bit drastic to change your ribbon to a toolbar at this late stage, simply to solve the RTF problem. But that's just my personal opinion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Ha! Mike was faster.

I also found that solution on Foxite.com: [URL unfurl="true"]https://www.foxite.com/archives/prevent-toolbar-from-undock-0000057504.htm[/url]
Of course, you need to dock it in init, if it isn't movable or set the DockPosition.

What remains is the "ugly" handle line at the left side of a toolbar suggesting to grab and move/undock it there. This, unfortunately, does not vanish, even when setting toolbar.Movable= .F.

I tried adding an oversized (wider than the display) page frame into the toolbar or set its position to a negative left position with both this.left=-10 and this.dock(0,-10,0), but the toolbar will always be at the left=0 position.

Bye, Olaf.

 

[Olaf Doschke]

Going back to what you said:

So maybe the answer is to convert those controls to a docked toolbar in the ribbon?

Well, you wouldn't make just a partial feature of a toolbar. You couldn't anyway. You can't dock a toolbar at some position within any other control, toolbars dock into a docking area anyway, they can't dock into other controls. The typical top docking area is just below a system menu and the rest of the form. Form.top=0 then begins below the docking area, so toolbars automatically push down any form content and the form controls and toolbars can't overlap or be part of each other anyway, toolbars only can hover above form elements when undocked, but then they simply are their own window. Otherwise they are only dockable to top, left, bottom or right part and make up their own form section not part of the form canvas, You can't ever dock something within the middle. You should know that once you used any toolbar of any application.

The only viable solution would be making the whole ribbon a single toolbar. Some aspects to make it non-movable and non-undockable are already solvable (see Mike), but as far as I know, you wouldn't want to have that look of the mover handle:

It's a bummer, isn't it? You can redo the tabs as you already did and have anything internal within the page frame the way you already have it, but you can't prevent that bummer, that yellow marked mover handle, which toolbars have.

What this solves is the focus problem. The focus stays. But that also introduces problems you face with any toolbar, like a modified value of the current control is not yet saved. Saving back anything in a control bound to some table or cursor or view field only updates this controlsource after the Valid event happened and returned .T., but that event only happens, if a control loses focus. If you have a save button, which then does a TABLEUPDATE of buffered changes, this saves all such buffered modifications, with the exception of the currently edited value. It's that downside of toolbar, which makes it quite fortunate you have the ribbon simply as a pageframe within a top level form, with the rest of the canvas just being the place for application forms.

But you have that other focus problem with the Richtextbox, now.

Bye, Olaf.

 

[Scott24x7]

Yeah. I get it. So the trade off is do it the hard way as container of controls in a function group on my ribbon bar, and manage the difficulty between forms (if you want the same UI look/feel), or do it the "easy" way (said sarcastically), and make it a toolbar, and deal with the location and visual issues.

So I will proceed with my difficult way, but trying more now to understand Olaf's suggested oSetting approach, rather than oRibbon approach. I don't mind re-doing it and taking a couple of days if the long term is better structure, and more flexible. I've already taken 3 weeks to "retool" the interface. I just showed it to one of our guys tonight, who is a main user, and he loved it, and the idea. So I would like to keep the modern feel going.



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

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

 

[Olaf Doschke]

About the oSettings vs oRibbon.

this is not just a renaming, I hope you got that already. I think of a goApp.oSetting object to exist anyway, to load in any application settings, of which current ribbon values would only be a subset of properties or sub-objects.

You have to go back to my idea of goApp not just being an object like goApp=CREATEOBJECT("empty") as a handle to any properties you add to it, but being an instance of a vfpApplication class, which offers functionalities and properties with the largest scope of public visibility. To not let it be a god class, you would implement it very lean and clean of just being a host for several specialist handlers, of which oSettings is just one, which is a manager of application settings, to load the settings at application start, to persist and maintain them, to validate their integrity, etc. All functionality about any setting. And mainly as it is a goApp sun-object that means application settings, whereas a font name or font size is just a property of a current text selection, but the nature of ribbon and form being two objects needing a third instance to "talk" to each other makes it a candidate to also have such "settings" as sub part of the oSettings handler.

Find another name, make it another object/handler/manager within goApp, if you dislike my proposal. But don't just get back to your idea to have a ribbon reference available within the richtextbox.

So before you get to understand goApp is more than just a global root variable for any global properties, but a host to several handlers each offering some core functionality to the whole application and any form within, maybe even to each other.

goApp, therefore, is composed of many classes which you can't simply do with OOP inheritance. Addressing and using goApp objects and properties means quite the same as making use of publicly inherited global functionalities, but VFP does not offer the type of inheritance of multiple parent classes.

I finally can't decide and dictate what you need and want. Anyway, goApp is more than just the giant ball of gum. It's a mixin host for everything of more general interest and a mediator, therefore, too. You show you learned a bit of OOP patterns using the term mediator. So you already got a right sense of this. I am confident you will get it.

Also look back what was the problem starting it all. You wanted to get rid of lengthy paths of object references like "Main.Pageframe1.basepage2.rtfControls.rtfFontSelect..." The idea about goApp.oRibbon won't do so, it just solves, what "Main" is in that context, but leaves the necessity to work with such long object path names. Also, doing it with this direct addressing of each other you make it hard to restructure the ribbon. Whenever you would move the fonts section or just the rtfFontSelect control to another layer/page/container, this object path will need to be adjusted anywhere it is used. At any relevant place, it is referenced... And there also is no good reason to have one object reference property in goApp for every ribbon tool or control to have a fixed name to the rest of the application.

goApp.oSettings is created at application startup or simple with the creation of goApp, which obviously also happens at application startup, it is the startup of the application, mainly. And goApp.oSettings
populates itself maybe from persisted values in a Settings.DBF file, so both the ribbon and any other form or control on an application form can rely on it to exist before them and address it. This is decoupling things. It seems more complex, as more is involved, but you can act from both sides of ribbon and control independently.

Bye, Olaf.

 

[Scott24x7]

This sounds really good. I hope I understand even part of it for now. It feels a little bit like "goAPP = Miracle Happens" in my laymans terms. Which I can accept for the moment if I can get it to work. Then I try to understand HOW and WHY it works after I see it in action. Believe me, I want to do this as you describe. It seems quite elegant, I just am struggling to understand how it "knows what it knows". Where assignments take place, and how it collects values. These are the mystery to me. I get it when I see goAPP.nFontSize = 10 or goAPP.nFontSize = This.Value. I see how it gets it's data. Or maybe I'm starting to get goAPP.oRibbon = This (from the Pageframe INIT). Also, makes sense.

So goAPP.oSettings = vfpApplication Class that starts to lose me. I'm not sure what this does, or what it contains or how it works.


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 can't tell you how it does the magic. You know where you store your settings, you know how to load them. If you do not have any code concerned with application settings, then your application has no settings, or you have just put things, which should be settings somewhere in properties or even constants you use in your code.

OOP is about designing the classes that become the active components of your application at runtime, and each dedicated to one major concern. If you don't have that, this is your major refactoring task.

Bye, Olaf.

 

[Olaf Doschke]

>make it a toolbar, and deal with the location and visual issues.

I don't know what location issues you mean, you can dock the toolbar to the top and have it non-movable, which means it stays where a ribbon is, you "only" have that visual issue.

Bye, Olaf.