Find dialog loses focus

[Tom Cone Jr]

Re: Find dialog loses focus

CAl, that was my first question. I infer from his posts that Ctrl-Y is the shortcut (hot key) on the button. -- tom

[Tim Kiebert]

Re: Find dialog loses focus

Just tested in a couple of forms in AlphaSports. I placed topparent.find() in the OnInit event and the find by key comes up with focus.

If all this button does is get activated when the form is opened then why not use the OnInit event to hold the code instead.

[CALocklin]

Re: Find dialog loses focus

Just tested in a couple of forms in AlphaSports. I placed topparent.find() in the OnInit event and the find by key comes up with focus.

If all this button does is get activated when the form is opened then why not use the OnInit event to hold the code instead.

Interesting discovery - I wouldn't have suspected that. HOWEVER....

Now I'm really confused. I decided to try Tim's method to see if it worked the same way for me. It didn't but I was testing it in a v8 app I already had open so I tested it in v9 and v10 also. While I was at it, I also created two test buttons, one with parentform.find() and one with sys_send_keys( "{^K}" ), and my results were that all three methods put the Find dialog in focus except in v8.

This leaves me confused because I know I had to change to using the sys_send_keys() in some of my apps because the .Find() wouldn't work. I can only guess that Alpha fixed the problem in V9 and I'm just remembering the issue from v8 (I swear I had problems in v9 but maybe it was only in earlier versions) BUT this thread is in the V10 forum - so what gives? Is it possible that an app originally created in v8 and now used in v10 carries over the issue? Or is there something else going on here?

EDIT: By the way, you don't have to activate a button to push it. Even if you haven't activated it, you can still use the sys_send_keys() action. Or, it would be better in my opinion to use Parentform:MyButtonName.push(). That way it would be easier to identify which button you were pushing when you edit the script a few months from now - assuming that you don't leave your buttons named as button1, button2, etc.

[Jeff Fried]

Re: Find dialog loses focus

I'm missing something here. Why are you using Ctrl-Y to open the Find dialog? Isn't the Find opened with Ctrl-K?

I've been using sys_send_keys( "{^K}" ) ever since Alpha "fixed" the way the Find dialog works so that now it doesn't have focus when opened with a "standard" .find action.

(FWIW: I don't think they really intended to "fix" anything. I think it just happened and they've never been willing to take the time to fix it. I know it was reported as a bug a long time ago. It worked fine in some earlier versions of A5 and maybe they finally fixed it in v11 but I don't have v11 yet since none of my customers are using or current need v11.)

Cal,

This is the first time I've heard that the loss of focus in this situation has been a bug in Alpha going way back. I'll bet it would have been easy to fix.

Regardless, the Ctrl-Y is simply the hot key for the button that brings up a find by customer name. I realize the standard default of Ctrl-K could also have been used. So I just tried it and it does not solve the problem -- still no focus. I didn't need to use a sys_send_keys regardless -- I could just have invoked the find dialog directly. I've tried just about everything I could think of, and nothing gives me focus except for the way I have it set up right now.

My setup is to push a hidden button that has a "Prompt for text" in which I put the title and prompt to what it is with the standard find dialog, then collect the variable from the user in order to find the record, in this case by company name. This would be completely fine except for one thing that I am currently trying to negotiate with my client.

First, this is only the situation when the user first goes in to the order entry screen from the Main Menu, meaning that the find used after that is the type that show auto completion, but with "Prompt for text" there is not auto completion. It's still the same number of keystrokes to find the name, such as when you're trying to find, say, "Smith" vs "Smith East". In both cases, you would type "smith e" to get to "Smith East". Just typing "smith" would take you to "smith", and the index is by name and inverse order date, so "smith" does not work for "smith east" -- it is not adjacent.

There is really no difference between typing "smith e" into the "Prompt for text" vs typing it into a built-in find dialogue except that after you type "smith e" you will see "Smith East" when using the built-in find dialog. For some reason, this seems to make a difference to this client, though I will need to see if the boss is really aware that the same number of keystrokes are necessary. It's about as much of a nit as you can get.

This being said, I would still like to satisfy the desire for 100% consistency between the two. So far I have not found the answer.

I tried Tim's suggestion using the OnInit event for the order entry form, with topparent.find(), and it did not come up with focus. Tim, I wonder what you did that gave it focus. Maybe it relates to the version of Alpha you are using. For reasons not necessary to go into here, this client with this application is using Alpha Five V7 since anything later that that (I tried them all except for 10.5 and 11) created a severe slowdown in the order entry process (I spent weeks trying to figure this out and finally had to succumb to staying with V7 -- it works very well with V7, even with Windows 7 using XP mode). There is clearly something about Alpha's adaptation to Vista, then Windows 7, that introduced the issue.

I appreciate the tips. I'll try anything and everything to solve this seemingly irrelevant problem. I just like to deliver exactly what is being requested without compromises, and it's usually not sufficient to say that there is a bug in Alpha Five that prevents it.

Jeff

[CALocklin]

Re: Find dialog loses focus

I'll bet it would have been easy to fix.

Yeah. See my last note. Apparently it was fixed in v9.

Any chance you could attach a "working" (so to speak) example? If not, would you consider letting me work with you remotely (contact info is on my website)? This is an interesting issue and I can't help thinking that something else is interfering with the normal operations in this case.

FWIW, I can see why the customer likes the "auto-fill as you type" method. It makes it easier to find out if the name you're looking for is even in there or if maybe you typed it wrong. I've even seen a method for doing that with xbasic but I don't recall the technique and I'd have to get permission from the customer to copy his code. His code isn't very generic so I don't use it myself but I think it would only take a small amount of work to converted it to something more generic.

[Jeff Fried]

Re: Find dialog loses focus

Yeah. See my last note. Apparently it was fixed.

Any chance you could attach a "working" example? If not, would you consider letting me work with you remotely (contact info is on my website)? This is an interesting issue and I can't help thinking that something else is interfering with the normal operations in this case.

I want to consider your offer to look at this directly. But since my last post, I tried the following:

I tested what would happen in version 10.5 vs. version 7 regarding focus of the find dialog after entry from a Main Menu. Here's what I found.

In version 10.5, there was one situation where focus was achieved. It's when you use "Find by key dialog (Standard)". The other find dialogs do not keep focus.

When I then tried this same "Find by key dialog (Standard)" using V7, it did not have focus.

My conclusion is that there was an attempt to solve this bug sometime between V7 and V10.5, but it was only applied to the "Standard" and not the "Custom" dialog.

I'll be back to you.

Jeff

[CALocklin]

Re: Find dialog loses focus

I see what you mean. I seldom use Action Scripting or the Xbasic Genie so I wasn't even aware of the "custom" method that uses .FindBy_DefinedKey().

You might want to try using this progressive lookup in the Code Archive that was originally created by Jim Chapman. It's the same one my customer's function is based on.

This lookup has the advantage that it shows a list of potential matches. I find it even better than a simple auto-complete. The user can just hit "Enter" once the correct result is highlighted or, as many users like to do, they can leave the keyboard, grab the mouse, move the cursor over the highlighted value, and double click to select it. (In case you couldn't tell, I hate seeing people waste time like that but a lot of them do it!) Of course, the user can also grab the mouse to select something that is further down the list and may take longer to type than to select with the mouse.

Note that you do have to add a little extra code to test the returned result and then use .recno_goto() only if the value is greater than 0.

[CALocklin]

Re: Find dialog loses focus

I finally figured it out why it doesn't work in the OnInit or OnActivate. And now I feel a bit stupid for not figuring it out sooner because I've run into it before.

The OnInit and OnActivate events fires before the form is actually visible. Therefore, when you do something like that in either of those events, it very briefly has focus but then the form is displayed and it "takes over" the focus.

The only solution I've been able to find so far is to use both the OnInit and OnTimer event:

OnInit:

DIM SHARED just_initiated as L
just_initiated = .T.

OnTimer:

DIM SHARED just_initiated as L	[COLOR="#0000CD"]'This isn't necessary here but I prefer it just so I know what the variable is when editing later.[/COLOR]
IF just_initiated
	parentform:find_btn.push()
	just_initiated = .F.
END IF

This requires a timer setting of about 0.5 seconds or less. Otherwise it seems like there's a long lag before the Find dialog shows up.

[Jeff Fried]

Re: Find dialog loses focus

I finally figured it out why it doesn't work in the OnInit or OnActivate. And now I feel a bit stupid for not figuring it out sooner because I've run into it before.

The OnInit and OnActivate events fires before the form is actually visible. Therefore, when you do something like that in either of those events, it very briefly has focus but then the form is displayed and it "takes over" the focus.

The only solution I've been able to find so far is to use both the OnInit and OnTimer event:

OnInit:

DIM SHARED just_initiated as L
just_initiated = .T.

OnTimer:

DIM SHARED just_initiated as L	[COLOR="#0000CD"]'This isn't necessary here but I prefer it just so I know what the variable is when editing later.[/COLOR]
IF just_initiated
	parentform:find_btn.push()
	just_initiated = .F.
END IF

This requires a timer setting of about 0.5 seconds or less. Otherwise it seems like there's a long lag before the Find dialog shows up.

Cal,

I didn't realize this was sitting there. Just happened upon it. Thank you for posting this, and I will try it shortly.

Jeff

[csda1]

Re: Find dialog loses focus

Hi Jeff, Cal et al,

First thing is SYS_SEND_KEYS() is a really bad command to use in general. The key is entered at the end of the current keyboard buffer, and is played back in an asynchronous manner as soon as keys are accepted. If focus changes for any reason (program control, user mouse clicks etc), the keys will be entered in the window with the focus (including a non-Alpha Five window). This is a bad method.

Second, using code to push a button is just a bad thing to do as well. It's essentially the same as calling a script, but with more overhead, and a whole lot more difficult to debug and maintain. Instead, put the code of the button where it needs to be, or create a function or script that does it, and reference in the button or code as needed.

Tom, while it is good technique to close something last in your code that is located on the same object, in Alpha, the current code executing will continue executing even after it closes (Once it is "loaded" by Alpha Five, it will be there until the code exits) , however, don't reference any item from what you closed, as it will not exist.

I will look to see if there is a an easy XBasic way to invoke the dialog, however, to set the focus to the find box, I believe if you just activate the form, the focus will return to the find by key. e.g

formpointer.activate()

[Jeff Fried]

Re: Find dialog loses focus

Hi Jeff, Cal et al,

First thing is SYS_SEND_KEYS() is a really bad command to use in general. The key is entered at the end of the current keyboard buffer, and is played back in an asynchronous manner as soon as keys are accepted. If focus changes for any reason (program control, user mouse clicks etc), the keys will be entered in the window with the focus (including a non-Alpha Five window). This is a bad method.

Second, using code to push a button is just a bad thing to do as well. It's essentially the same as calling a script, but with more overhead, and a whole lot more difficult to debug and maintain. Instead, put the code of the button where it needs to be, or create a function or script that does it, and reference in the button or code as needed.

Tom, while it is good technique to close something last in your code that is located on the same object, in Alpha, the current code executing will continue executing even after it closes (Once it is "loaded" by Alpha Five, it will be there until the code exits) , however, don't reference any item from what you closed, as it will not exist.

I will look to see if there is a an easy XBasic way to invoke the dialog, however, to set the focus to the find box, I believe if you just activate the form, the focus will return to the find by key. e.g

formpointer.activate()

Hi Ira,

I believe I once tried the approach to activate the form, but if you see a way to do it and keep focus, that would be quite a find. Let me know if you do. Thanks.

Jeff