Announcement

**MikeC** · 05-07-2010, 10:55 AM

Re: x_dialog Killfocus event

Tom,
I just parsed down your xdialog so that I could use it in the interactive window, added a messagebox, and found you are trapping the killfocus just fine.....so must be a different issue....

**Tom Henkel** · 05-07-2010, 10:58 AM

Re: x_dialog Killfocus event

I realize I have coded to capture the event. The event is NEVER firing! see the code for clog. That is just our own internal trace of events.

Tom

**MikeC** · 05-07-2010, 11:12 AM

Re: x_dialog Killfocus event

I must not be understanding what the issue is Tom. Whenever I leave the Segment field the messagebox I placed after your killfocus fires....which to me indicates it is working.

What else did you want to happen....and can we reproduce it or the failing with the script you provided or do we need the supporting tables--or an example with hard coded values would work as well really.

**Tom Henkel** · 05-07-2010, 11:13 AM

Re: x_dialog Killfocus event

I just ran a very quick test. I changed the field to just be a straight data entry field instead of a record list combo box, and the killfocus event fired.

Seems like a problem to me...

Tom

**MikeC** · 05-07-2010, 11:24 AM

Re: x_dialog Killfocus event

I am testing against an "odd" build that most likely is different from yours---indicate your build and maybe someone with the same could test it for you to confirm.....

**Tom Henkel** · 05-07-2010, 11:30 AM

Re: x_dialog Killfocus event

2095 3264

**CALocklin** · 05-07-2010, 06:21 PM

Re: x_dialog Killfocus event

You are quite correct. Those particular field objects do not give you a KillFocus event.

Try this. I left your "Segment" field and added a "Segment2" field. The result is a bit different because the description ends up showing in the field but it works if that's acceptable.

I used tabs to create the list of choices - mostly because that lines up the fields making it easier for the user to read.

The delimiter between the fields isn't really needed in this case because all you really need to get is the first 'word'. However, since you might need to parse the full line in some other situation, here's the logic:

1. The first tab, {T=20}, sets the "field delimiter" (I used a space, 2 pipe symbols, and another space in this case) position to 20 inches which should be way to the right of the drop-down so it isn't visible then the second tab sets the position of the next field to 0.5 inches. These tabs only set the the display location so going back and forth like that to hide delimiters is not a problem. If I had 4 fields and wanted delimiters between each, I might do something like this:
"field1+'{T=20} || {T=.4}'+field2+'{T=20} || {T=1.4}'+field3+'{T=20} || {T=2.6}'+field4"

2. The result returned does not have any of the tab info in it. This means that my example above might return the following. Note that "field2" is really long and would not show completely in the drop-down because it is longer than 1 inch of text - but it still shows up in the result.
JCAD || This is the long field that only displays 1 inch. || This is field 3. || And this is field 4.

I also changed your first CASE statement to:
word( vSEGM, 1 )$"CCPD,GO,JCAD,TTW,MOCM,MOAL,JCNH,MONH"
because it got really, really long now that I had to use word( vSEGM, 1 ) to get the segment ID. A couple warnings about this. First, if it's possible that one ID might be embedded in another, you might have to use something like inlist() or inlist2(). Second, if the vSEGM value is blank, it will always be found in the list when using "$" - makes sense if you think about it.

Also note the %O={@@}% used in the control definition. (I don't know why but the forum is underlining that.) This tells it that the input list is formatted with the tabs.

FWIW....

I've always hated the keylist build. It's just to complicated to be easy to edit.

And, just to give you another idea, I changed the %code% section to use ELSEIF rather than a series of IF statements. There are 2 reasons for that: (1) it might be faster because it doesn't need to evaluate the other IF statements once a match is found (and since we are just looking for a match on the a_dlg_button value, we only need to worry about the first match) and (2) I think it's easier to "see" because I know that all the ELSEIF sections belong "together" whereas sometimes with long %code% sections I'm not sure if I'm still inside the %code% section when each IF is separate. This is not a big deal but just something that I believe makes it easier for me to 'read'. This is especially true when I want to just scan past a long %code% section - if I'm still seeing ELSEIF statements as I page down then I probably haven't gotten past it yet.

Here's the modified code:

Code:

'Date Created: 05-May-2010 02:54:53 PM
'Last Updated: 07-May-2010 05:40:29 PM
'Created By  : Thomas Henkel
'Updated By  : Cal Locklin
'Create an XDialog dialog box to prompt for parameters.

agency = "Joe's Bar"  'Added by Cal for testing.
 
dim global cLOG as C
cLog = ""
DIM clt as P
DIM lnk as P
DIM SHARED vCASENO as C = ""
DIM SHARED vSSN as C
DIM v65 as L
DIM SHARED vNAME as C = ""
DIM SHARED vPGM as C = ""
DIM SHARED vSEGM as C = ""
DIM SHARED vIWORKER as C = ""
DIM SHARED vCWORKER as C = ""
DIM SHARED vSWORKER as C = ""
DIM SHARED vDATE1 as D = {}
DIM SHARED vDATE2 as D = {}
DIM SHARED vACTION2 as C = ""
DIM SHARED vDATE3 as D = {}
DIM SHARED vSTATUS as C = ""
DIM SHARED vSTAT_DATE as D = {}
DIM SHARED vFILEROOM as C = ""
DIM SHARED vCREASON as C = ""

DIM SHARED vDREASON as C = ""
DIM SHARED vERROR as L
DIM SHARED varC_result as C
DIM vSEG_rl_def as C
DIM vPGM_rl_def as C 
DIM vIWORKER_rl_def as C 
DIM vCWORKER_rl_def as C 
DIM vSWORKER_rl_def as C
DIM vACTION2_rl_def as C 
DIM vSTATUS_rl_def as C
DIM vCREASON_rl_def as C 
DIM vDREASON_rl_def as C 
 
'debugcheck()
clt = table.open("client",FILE_RO_SHARED)
'clt = table.current()
vSSN = clt.ssn
if clt.dob < addyears(date(),-65)
    v65 = .T.
  else
      v65 = .F.
end if
vNAME = UT(clt.fname)+" "+ut(clt.lname)
'lets first determine if the client already has a case number
lnk = table.open("LINK",FILE_RO_SHARED)
lnk.index_primary_put("Ssn")
foundit = lnk.fetch_find(vSSN)
if foundit > 0
    if isalpha(left(lnk.Case,1))
        vCASENO = lnk.Case
      else
          if left(right(trim(lnk.case),6),1)>"3"
              vCASENO ="S"+right(trim(lnk.case),6)
            else
                vCASENO = "C"+right(trim(lnk.case),6)
          end if
    end if    
  else
    script_play_local("reg new case number")
end if
if vERROR
    end
end if
vSEG_rl_def = "k=segment,{keylist_build(\"H=.05,1:9,2:35\",''+Seg,left(''+Seg,9),left(''+Describe,35))}{}"
vPGM_rl_def = "k=pgm,{keylist_build(\"H=.05,1:9,2:25\",''+Pgm,left(''+Pgm,9),left(''+Desc,25))}{}"
vIWORKER_rl_def = "k=workers,{keylist_build(\"H=.05,1:8,2:25\",''+Wcode,left(''+Wcode,8),left(''+Wname,25))}{between(left(wcode,1),\"A\",\"B\").and.left(WCODE,3)<>\"ADM\".and.left(wcode,2)<>\"AM\".and.left(wcode,2)<>\"AP\".and.left(wcode,2)<>\"AX\".and.left(wcode,2)<>\"BD\".and.left(wcode,2)<>\"BT\"}"
vCWORKER_rl_def = "k=workers,{keylist_build(\"H=.05,1:8,2:25\",''+Wcode,left(''+Wcode,8),left(''+Wname,25))}{between(left(wcode,1),\"A\",\"B\").and.left(WCODE,3)<>\"ADM\".and.left(wcode,2)<>\"AM\".and.left(wcode,2)<>\"AP\".and.left(wcode,2)<>\"AX\".and.left(wcode,2)<>\"BD\".and.left(wcode,2)<>\"BT\"}"
vSWORKER_rl_def = "k=workers,{keylist_build(\"H=.05,1:8,2:25\",''+Wcode,left(''+Wcode,8),left(''+Wname,25))}{left(wcode,2)=\"AM\".or.left(wcode,2)=\"AP\".or.left(wcode,2)=\"AX\".or.left(wcode,2)=\"BD\".or.left(wcode,2)=\"BT\"}"
vACTION2_rl_def = "k=caseact,{keylist_build(\"H=.05,1:10\",''+Action,left(''+Action,10))}{}"
vSTATUS_rl_def = "k=status,{keylist_build(\"H=.05,1:4,2:25\",''+Status,left(''+Status,4),left(''+Desc,25))}{}"
vCREASON_rl_def = "ke=closerea,{keylist_build(\"H=.05,1:6,2:15,3:25\",''+Closecode,left(''+Closecode,6),left(''+Category,15),left(''+Describe,25))}{}"
vDREASON_rl_def = "ke=denyreas,{keylist_build(\"H=.05,1:6,2:15,3:25\",''+Denycode,left(''+Denycode,6),left(''+Category,15),left(''+Describe,25))}{}"
 
seg_list = table.external_record_content_get( "segment", "left(seg,9)+'{T=20} || {T=.4}'+trim(describe)","seg" )
vPGM = "MED"   'Added by Cal for testing.
 
heading_string = vNAME+"   -   Case No: "+vCASENO+crlf()+"Case Information Entry"
ok_button_label = "&OK"
cancel_button_label = "&Cancel"
varC_result = ui_dlg_box(agency+ " Customer Information",<<%dlg%
{Background=#234+255+255}
{region}
{text=45,2:heading_string};
{endregion};
{line=1,0};
{lf};
{region}
Program: [%@vPGM_rl_def%.10vPGM]{sp=5}
Segment: [%@vSEG_rl_def%.10vSEGM];
Segment2: [%O={@@}%.40vSEGM^=seg_list!vSEGM_*];
{lf};
Application Date: [%DATE;P=popup.calendar(dtoc(vDATE1));I=popup.calendar%.15vDATE1!vDATE1_*]{sp=3}
Registration Date: [%DATE;P=popup.calendar(dtoc(vDATE2));I=popup.calendar%.15vDATE2!vDATE2_*]{sp=3}
Registration Action: [%@vACTION2_rl_def%10.20vACTION2];
{lf};
Intake  Case Worker: [%@vIWORKER_rl_def%.10vIWORKER]{sp=5}
Ongoing Case Worker: [%@vCWORKER_rl_def%.10vCWORKER]{sp=5}
Service Case Worker: [%@vSWORKER_rl_def%.10vSWORKER];
{endregion};
{lf};
{region}
Case Status: [%@vSTATUS_rl_def%.8vSTATUS]{sp=3}
Status Date: [%DATE;P=popup.calendar(dtoc(vSTAT_DATE));I=popup.calendar%.15vSTAT_DATE!vSTAT_DATE_*]
{endregion}{sp=3}
{condition=(vSTATUS="C")}
{region=a}
Close Reason: [%@vCREASON_rl_def%.8vCREASON]
{sp=3}
{condition=(vSTATUS="D")}
{start_pos}
Deny Reason: [%@vDREASON_rl_def%.8vDREASON]{endregion};
{condition=.T.}
{region}
{lf};
Close Date: [%DATE;P=popup.calendar(dtoc(vDATE3));I=popup.calendar%.15vDATE3!vDATE3_*];
{lf};
File Room:  (vFILEROOM:3) (vFILEROOM:4)
{endregion};
{line=1,0};
{region}
<*15=ok_button_label!OK> <15=cancel_button_label!CANCEL>
{endregion};
%dlg%,<<%code%
 
'*******HERE is where I am attempting to trap the event ***********
if left(a_dlg_button,6) = "vSEGM_" then
    clog = clog+a_dlg_button+crlf()
    if a_dlg_button = "vSEGM_killfocus"        'debug(1)
        'determine if Medicaid,  If so, change case number to appropriate "02" number
        if vPGM = "MED"
            SELECT
                case word( vSEGM, 1 )$"CCPD,GO,JCAD,TTW,MOCM,MOAL,JCNH,MONH"
                     if v65
                         vCASENO="0210"+right(trim(vCASENO),6)
                       else
                           vCASENO="0220"+right(trim(vCASENO),6)
                    end if
                case word( vSEGM, 1 )="MNC".or.vSEGM="MNNH"
                     if v65
                         vCASENO="0215"+right(trim(vCASENO),6)
                       else
                           vCASENO="0225"+right(trim(vCASENO),6)
                    end if     
                case word( vSEGM, 1 )="FAM"
                     vCASENO="0230"+right(trim(vCASENO),6)
                case word( vSEGM, 1 )="FCA"
                     vCASENO="0270"+right(trim(vCASENO),6)
                case else
                    vCASENO = vCASENO
            END SELECT        
            'refresh the heading string
            heading_string = vNAME+"   -   Case No: "+vCASENO+crlf()+"Case Information Entry"
        end if
    end if 
    a_dlg_button = ""
ELSEIF left(a_dlg_button,7) = "vDATE1_" then 
    if a_dlg_button = "vDATE1_killfocus" then 
        vDATE1 = ctod(dtoc(vDATE1))
    end if 
    a_dlg_button = ""
ELSEIF left(a_dlg_button,7) = "vDATE2_" then 
    if a_dlg_button = "vDATE2_killfocus" then 
        vDATE2 = ctod(dtoc(vDATE2))
    end if 
    a_dlg_button = ""
ELSEIF left(a_dlg_button,7) = "vDATE3_" then 
    if a_dlg_button = "vDATE3_killfocus" then 
        vDATE3 = ctod(dtoc(vDATE3))
    end if 
    a_dlg_button = ""
ELSEIF left(a_dlg_button,11) = "vSTAT_DATE_" then 
    if a_dlg_button = "vSTAT_DATE_killfocus" then 
        vSTAT_DATE = ctod(dtoc(vSTAT_DATE))
    end if 
    a_dlg_button = ""
end if
%code%)
 
if varC_result <>"OK"
    ui_msg_box(Agency+" Customer Information","Action cancelled at user request")
    end
end if

**Tom Henkel** · 05-08-2010, 05:53 PM

Re: x_dialog Killfocus event

Thanks, Cal. I'll see what happens with this on Monday. The reason for this whole dialog is that pesky field rule lookup problem and the fact of Alpha coming to its knees during Data Entry.

Tom

**Mike Wilson** · 05-08-2010, 06:56 PM

Re: x_dialog Killfocus event

This was a problem I discovered and posted in this thread:
http://msgboard.alphasoftware.com/al...ight=killfocus

**Tom Henkel** · 05-10-2010, 10:24 AM

Re: x_dialog Killfocus event

Cal,
I've inserted the code, and it does definitely allow for the killfocus event. The only problem now is that, for the most part, the input operators will be keying in the segment as opposed to selecting it. Data Entry operators usually key in information rather than using the mouse to select things. It slows them down. The field takes the keystrokes and chooses whichever segment is closest to the last key entered. When I key in MONH (Medicaid Only, Nursing Home), the selection becomes HMGO (Homemaker Services - Global Options). You can see where this might cause a problem.

Mike,
I read through you thread. Did you ever get any resolution to the issue in ver 10?

Tom

**Mike Wilson** · 05-10-2010, 10:41 AM

Re: x_dialog Killfocus event

Tom,
No I did not. I used the example that Ira provided to learn the intricacies of the events and eventually ended up using setfocus events on the fields that followed instead of killfocus events to run codes.

LATER:
I retried it with newest v10 update and Ira's event tracker dialog example and there is a killfocus event that fires when leaving an xdialog combo box now. Selwyn got it fixed!

**Tom Henkel** · 05-10-2010, 10:52 AM

Re: x_dialog Killfocus event

...and herein lies my frustration. We always seem to have to write around something that should work, but doesn't.

I am writing a lot of code to perform the function of field rule events that have worked very well in version 1 (yes, version 1) and version 5. This application has been solid for over 10 years. Version 9 was the first version that showed enough speed to have us consider upgrading. In March, after a year of converting code, we attempted to go live with our system. It was a major debacle. Users were locking each other out right and left. Field rule lookup tables were not defined appropriately, in fact, their path definition was missing. We spent 2 days attempting to fix problem after problem, then finally retreated to a solid version 5. After consulting with others, We bit the bullet and are writing x-dialogs to perform data entry for our client information system. There should be no lockouts, but we have to write an enormous amount of code to simulate all of the things that were done in field rules. We brought the lookup issue to Alpha as a bug, and were told, "yes, it is a bug", and "here is the fix for ver 10". We're not running ver 10.

Tom

**Mike Wilson** · 05-10-2010, 10:53 AM

Re: x_dialog Killfocus event

Tom, see my later: note above.

**Tom Henkel** · 05-10-2010, 10:57 AM

Re: x_dialog Killfocus event

In ver 10. We spent a lot of money on multiple developer's licenses and unlimited Run Engine for ver 9. Do I now go back to my board and say, we need more money because the software we bought last year is obsolete? I like my job, and would really rather keep it.

Announcement

The Alpha Software Forum Participation Guidelines

x_dialog Killfocus event

x_dialog Killfocus event

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment