Looking for help on an Idea for Navigation 1

[Scott24x7]

Hi All,
So I've spent a couple of days trying to get something to work, have taken a few approaches, but seems to lead me to a dead end.
I have a set of graphic objects (flags) that I have placed on a map. The flags are only "visible" when their location matches to the client. So some clients have more than one office in the city, so I have a routine that counts the number of locations and displays it in a label over the flag.
What I want to do now is expand that, so when you "hover" over the flag, a small list (like "tool-tip text") pops up with the list of locations for each one. I tried using a dynamic drop-down box, and I got the items to list, but getting the box to "appear/disappear" didn't work well. (It would appear, but I couldn't select items, and the box would not disappear after click or leaving it (even having This.Visible = .F. in the MouseLeave or LostFocus events.)

I thought maybe a list box would be the best way to do it, but the "MouseEnter" on the flag field isn't taking into consideration the entire flag. One problem is, the flags overlap too, so ZOrder is a problem, as flag that's not visible, but "on top" of another flag interferes with the MouseEnter issue.

The flag and the textbox are in a Container and it seems the boundary of the container also impacts things like "tool-tip text" (it fires on leading right edge and bottom edge, but not on top or left side...)

I think the idea is a cool one, as it would allow "1-click navigation" visually within the form, rather than having to click on other buttons or lists to get to them.

Has anyone else implemented something like this? I feel I've "over complicated it", but I've been fighting with the controls for 2 days.
Thanks for any suggestions.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

Thanks Mike,
It works pretty well, and I like the just "move away" or pick something element (as my philosophy is: clicks are bad). That is a challenge to implement in VFP which was before "clicking" became a big deal.
The only other way I could come up with was to write a value out to a text file, and then re-read that in when the call returns. But that seems horrendously messy. Or, I suppose I could create (gasp) a global variable... that would should send the dev purists right over the edge...


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Mike Lewis]

The only other way I could come up with was to write a value out to a text file, and then re-read that in when the call returns. But that seems horrendously messy. Or, I suppose I could create (gasp) a global variable.

But you would have the same problem with both of those ideas. The point is that, if the grid form is modeless, the parent form has no opportunity to pick up the returned value. After the parent calls the child, it (the parent) will just sit there waiting for events. Meanwhile, the user is interacting with the child. The parent has no way of knowing when the user has made a selection, and there is no opportunity for it to act on that selection - no matter whether the selection is made to a global variable, a text file, or whatever.

(I suppose you could fire a timer in the parent to check for the existence of the text file or whatever, but that might have other unwanted implications.)

In fact, Olaf has suggested a possible approach using the parent form as a parameter to the child form.

The parent form would have a custom method which processes the users selection in some way. It would receive that selection as a parameter (this is the same value that you would otherwise return from the modal form). Let's call that method Process.

Now, when calling the child form, the parent form would pass THISFORM as a parameter. In the child form's Init, store that reference in a property (of the child form), called, say, oCaller.

At the point at which the user makes the selection, the child form would call THISFORM.oCaller.Process(SelectedValue), where SelectedValue is the value that the user has chosen. The parent would then immediately process the selection - while the child form is still open. That point is important, because it means that the user will see the effect of the selection straight away, and can continue to interact with the child form if he changes his mind.

In fact, you could take this approach regardless of whether you close the child form by clicking outside it or moving the mouse outside it. But it does mean that the child form could now be modeless, which could be a good advantage.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Yes, you can callback or call .Process at any time, not only when the deactivate event occurs. That gives a lot more possibilities. Just notice, the more specific you get with oCallerform or oCaller as Mike named it, the more all this code is bound to be used with that single parent form having all the methods, properties or even controls you may act on. Keep the interface simple, and you can reuse that for many more situations something rather needs a popup form than a control you create on some form.

If you limit yourself to acting on some returnvalue property or a Callback or Process method, you could define that as general contextform and reuse it everywhere you need more than just a simple context shortcut menu. Put that base behaviour in a base contextform class and then specialize in child classes doing more specific things.

Bye, Olaf.

 

[Scott24x7]

Hi Mike and Olaf,
At the conceptual level I think I kind of get what you mean, but do either of you have a simple example in code how it might work? (I don't need the form just, how the calls within code in the child form and from the parent form, what events they would be in?) I'm admittedly a bit weak in this area of OO programming, and sometimes it feels a bit voo-doo to me. Happy to learn it, as it sounds ridiculously useful, but some base example would be greatly appreciated.

As a side note, I can tell I'm getting a bit better at this, as I just reviewed my navigation and removed huge sections replacing with a couple of calls that I've learned here over the past few months, mostly from the two of you and Tore. So my thanks on this. I know it comes easy to you both, but not so much for me these days.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

Hi Olaf,
Sorry, I think something weird happened in reading the thread while it was open and not refresh, I missed your post about 4 up where you show this! Either that or there is some timing issue with when the thread posted. But thanks. I see it now, in the next couple of days I'll see if I can make this work in what I already have. It's been 4 days to get to this point and I'm pretty burned out on this issue. Thought it would take maybe 1/2 a day, and now its ground me to a halt on a ton of other things (not related to this, but all the time I needed to be spending on "real" work).
I hope to advance a bit here with this, so I have to expect to spend another 1 - 2 days to get this method ironed out. It sounds like a very clever and useful way to go though.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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