×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Force a form to deactivate and let another activate

Force a form to deactivate and let another activate

Force a form to deactivate and let another activate

(OP)
I have a pair of forms that are related (in a parent/child kind of way). There's code in my framework so that if I move the record pointer in the parent form, the child form moves to the corresponding record. That's all working.

This application allows only one form to be in edit mode at a time, so there's framework code in the main data entry form class's Deactivate method that checks whether the form being deactivated is in edit mode and if so, prompts the user to either cancel the edit or stay on the current form.

What I'm working on now is having a textbox on each of these two forms where the user can scan a barcode and it will position the parent form on the record indicated by the barcode and then open or position the child form on the corresponding record in edit mode. That is, if the child form is not open, open it; otherwise, just reposition. But in either case, switch to edit mode.

If the child form is closed when I do this, the scan textbox on the parent form works as I need it to. But if the child form is already open, I see the message about having to either cancel the edit or stay put. What's happening is that to do what we need, we have to refresh the parent form (which then allows us to update the child form using a custom method).

The problem is that having done so, the parent form has focus, and I can't find a way to force it to deactivate and hand focus over to the child form before I switch the child form into edit mode. I've tried using ACTIVATE WINDOW, and setting focus to a control on the child form, and doing both, and I still see that the parent form's Deactivate method doesn't fire until after the code that changes the child form's mode.

So I'm looking for a surefire way to have the parent form's deactivate run when I want it to (other than closing the parent form). Any ideas?

Tamar

RE: Force a form to deactivate and let another activate

Can you shrink this down to a runable demo? I mean I could try, but the ingredients are not all clear to me.

I understand the main problem is to avoid a deadlock problem of the security prompt and my first instinct was how about introducinng a mode that overrides this interaction and allows to switch anything you need to switch programmatical even if it needs to violate something for a short moment. The other thing I usually think about to solve such timing problems is running a timer that does what's necessary to do in say just 1 or 10 ms and then release.

Well, the detail question is what triggers a deactivate, isn't it?

You said both forms have the barcode textbox, and the problematic case is the child form is open and in edit mode (by the automatism of a first barcode), so shouldn't the second barcode scan be on the childform textbox? Why would a user activate the parent form to scan, right? So couldn't the barcode processing code in the child forms barcode textbox end the edit mode to be able to do everything necessary everywhere and end up in the records for the new barcode in parent and child with child form put into edit mode again?

Or is the barcode scanner programmed with a prefix hotkey that always activates only the parent barcode textbox?

Well, you see I struggle a bit to get my head around this whole setup, but maybe that's already giving you ideas.

Chriss

RE: Force a form to deactivate and let another activate

One thing I remember is that one of the reasons bindevent to windows events was introduced is to enable reacting to the deactivation of _screen to detect and react to application switching. And I guess that could also be used to detect an active form change, though that's not what you need here, you have form activate and deactivate for that. But maybe it works better or different and easier to program than the deactivate event, because in bindevents you can choose the delegate to act before or after the actual event, can't you? So that's another arrow in the quiver, isn't it?

Chriss

RE: Force a form to deactivate and let another activate

I experimented with eventtracking (not helpfull when both forms are logged as form1) and then simply debugout in activate/deactivate events and what I see is that the active forms deactivate always runs before the activate event of the form becoming active, so the natural order, nothing unusual.

So, when your child form has focus and refreshes the parent form which, as you say, gets focus by that refreshing, then firstly child deactivate will run, secondly parent activate and then something in parent should put focus back to the childform, which would cause parent deactivate before child activate. I don't see where the problem is.

Quote (Tamar)

and I still see that the parent form's Deactivate method doesn't fire until after the code that changes the child form's mode.
Where's the code that changes the child forms mode?

Quote (Tamar)

But if the child form is already open, I see the message about having to either cancel the edit or stay put.
That's to be expected, isn't it? As you say the parent form becomes activated by refreshing - I don't see this happening if I just would call parentform.refresh, but you seem to do more. In itself no problem, but then wouldn't it be good as I said in my first response to have a mode that suppresses this message or automatically ends editmode of the child form before refreshing parent and finally activate editmode after navigation in the child?

I would say when the child form receives a new barcode through its barcode textbox while it's in editmode of a previous barcode, should the first act not be ending the editmode and saving all changes necessary associated with the previous barcode and then continue from there with the new barcode? And wouldn't that already solve all problems involved in unwanted prompt messages?

The last thing I think is when any code for parent form refreshing activates the parent form, that activation event can only occur when VFP comes back to READ EVENTS (is idle), not while the code causing it runs, so if you then want to put focus back to the child the focus change to parent may not have been done yet so setting focus back could only happen as aftermnath anyway? If that's the case a time running just once could help and also DOEVENTS could help to let the event happe that are triggered by code before it actually finishes.

Chriss

RE: Force a form to deactivate and let another activate

(OP)
Thanks, Chriss, with your suggestion about turning off that check in Deactivate, I'll solved this. I added a property to the form class, normally .F., and set it to .T. at the beginning of this process and back to .F. in the end. In the framework-level Deactivate, I check this flag and if it's .T., just skip the test for being in edit more.

That's a little clunky, but as long as we're careful about when we set that flag, all should be well.

Also, should have said earlier that these textboxes aren't available in edit mode, only in view mode.

Tamar

RE: Force a form to deactivate and let another activate

I wonder if it wouldn't be simpler to change from edit to view mode and back instead of introducing this new flag, but glad you resolved the issue.

Chriss

RE: Force a form to deactivate and let another activate

(OP)
When this process starts, we're in View mode, but the goal is to end up in Edit mode. Basically, the idea is that a user should be able to scan a barcode and, regardless of which of the two forms they started on, wind up on the child form in edit mode.

Tamar

RE: Force a form to deactivate and let another activate

I dopn't see why that can't be done the other way, i.e. if in editmode switch to view mode, trigger the change by barcode and go back to edit mode. If you're still in view mode, there's nothing to do, initially, but so what?
The only problem was the child window being in edit mode while the new barcode causes change navigation/refresh, wasn#t it, and first turning back to viewmode would solve that without a dirty flag, wouldn't it?

Chriss

RE: Force a form to deactivate and let another activate

(OP)
No, when the barcode was scanned, both forms were in view mode. The barcode textboxes are disabled in edit mode.

The problem was that even though I was putting the right form into edit mode at the right time, at that moment, the parent form had focus, and because (for historical reasons and very hard to change at this point) the form mode is a global thing, when the parent form finally deactivated, it thought it was in edit mode and so, showed that message.

Tamar

RE: Force a form to deactivate and let another activate

Ah, that explains it - I think.

Well, as you stated yourself:

Quote (Tamar)

as long as we're careful about when we set that flag, all should be well.

I don't assume you're not careful, but that little caveat made me think it could be solved with the mode setting, too, it becomes clearer why you searched for a way to reliably trigger the form activation. I think you could do so with SetActiveWindow or sending WM_ACTIVATE and other messages. It's not really worth digging into details. While the solution may remove the need for the flag, it would dig deep just for getting things done in the exactly wanted and controlled order of events. Just to break under some untested conditions.

Chriss

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close