Hi all…it's been a long time since I've posted here, mostly cuz I've not been doing any real development in my funky little system. But the Boss is hankering for a deployment so that other victims, er, coworkers can work with these databases so here I am begging for assistance.

OI Forms. Vey!

Question #1) Does adding a CREATE quickevent to a form necessarily cause other innate CREATE procedures to not occur?

Background: I have noticed this with both database-enabled and non-database-enabled (formerly called "collector" windows in ARev) that when I add a CREATE quickevent, the form title no longer appears in the window titlebar on testrun or execute. The form title continues to appear properly in FORM DESIGNER, but not when the form is actually run. When the CREATE quickevent is removed, the title reappears on execute.

The CREATE quickevent that I'm adding to the forms is the ETSETCASE procedure written by Chris Salese (RTI Support), the source of which is:

subroutine ETSetCase( CtrlEntID, Cols, Upper)

* This subroutine can be used to force a specified

* column in an EditTable to be uppercase only.

* Chris Salese

* Revelation Support

* July 9, 1996

*

* Instructions how to use:

*

* This subroutine must be placed in the Form CREATE event.

* More than one edit table may be passed to this subroutine

* in a space or @vm delimited list.

*

* Proper syntax in the CREATE event is:

* In Send Message To: PINUSA*STPROCEXEETSETCASE * In Parameters: 'formname.edittablename', 'col#', 'true$' * * Note: The underlying data remains as it was actually entered. * To convert the stored data to uppercase, a "CONVERT * @LOWER_CASE TO @UPPER_CASE" * statement must be added to the LOSTFOCUS event. * declare function Get_Property declare subroutine SendMessage $insert Logical equ WM_USER$ to 1024 equ DTM_SETCOLFORMAT$ to WM_USER$ + 18 if assigned(Cols) else Cols=' if assigned(Upper) else Upper=' if len(cols) else cols=1 if len(upper) else upper=TRUE$ convert '' to @vm in cols hWnd=Get_Property(CtrlEntID, "HANDLE") if hWnd then Format=str("lu"not(not(Upper))+1,1,119): \00\ rcol=' rflag=' loop remove col from cols at rcol setting rflag While col SendMessage(hWnd, DTM_SETCOLFORMAT$, Col - 1, GetPointer(Format)) repeat end return 1

LOSTFOCUS SCRIPT TO UPPERCASE UNDERLYING DATA:

declare function get_property

declare subroutine set_property

ans=get_property( @window:".controlname", "LIST" )

* "LIST" causes values on all rows of the EditTable to convert

* whereas "ARRAY" or "TEXT" only causes the final row to convert

convert @lower_case to @upper_case in ans

set_property( @window:".controlname", "LIST", ans )

return 1

***

Rather than always having to write a commuter module (on small, "collector window" type forms that merely pass data to an executable procedure, a commuter module sometimes seems like more work than is necessary), should some code be added to the above to force the form title?

Question #2) Speaking of the ETSETCASE procedure (and the LOSTFOCUS conversion of underlying data from @lower_case to @upper_case), I find that the when the cursor is forced to leave the EDITTABLE (Ctrl-Tab), the visual values in the rows of the EditTable to be uppercased are then finally uppercased. This is fine in a non-databound form, but in a databound form that has verifile validation, since the uppercase conversion is not performed until after leaving the edittable, it seems to me that the validation would necessarily fail, seeing as the lowercase record id being tested does not exist.

How could I alter the above so that each row of data in the edittable is converted to uppercase when Enter is pressed so that it would pass the verifile validation?

Question #3) This is my final question in this go around. In my data-bound forms, I *have* actually written commuter modules to handle various processing needs. One of the needs is to duplicate the " (double-quote) function in Default value from ARev Windows (wherein the value of a prompt from the previous record becomes the default prompt data value in the next record). To do this, the commuter copies the entire record to @USER1, coverting @fm to @vm, @vm to @svm, etc. In a new record, when the cursor reaches a field that calls upon this default function, the control contains the appropriate default data value. This works perfectly for edit boxes, however in edit tables, I get Value1 Value2 on row 1 instead of Value1 in row1 and Value 2 in row2. I have tried a few different properties and the closest I can come is: Value1 Value2 in row1 and Value2 in row2. So I *am* getting closer to a solution but thought some kind soul here could give me a leg up.

Thanks in advance,

Mike Parrish

Hey Mike,

It's been a while. Good to see you around again. I thought the boss was going another route rather than OI…

Question #1) Does adding a CREATE quickevent to a form necessarily cause other innate CREATE procedures to not occur?…the form title no longer appears in the window titlebar on testrun or execute. The form title continues to appear properly in FORM DESIGNER, but not when the form is actually run. When the CREATE quickevent is removed, the title reappears on execute.

In your QuickEvent you should remove the @SELF in the Control field and the TEXT in the Property field. This is what's causing the clearing of your title bar.

Question #2) Speaking of the ETSETCASE procedure (and the LOSTFOCUS conversion of underlying data from @lower_case to @upper_case), I find that the when the cursor is forced to leave the EDITTABLE (Ctrl-Tab), the visual values in the rows of the EditTable to be uppercased are then finally uppercased…How could I alter the above so that each row of data in the edittable is converted to uppercase when Enter is pressed so that it would pass the verifile validation?

It's been awhile since I've looked at the processing order of validation versus POSCHANGED events but you might be able to trap the POSCHANGED event at the Script level and then uppercase the entry within the edittable yourself. Then the Verifile should go through. Alternatively, you could remove the Verifile and put your own custom validation in the POSCHANGED/LOSTFOCUS event for the edittable.

Question #3) This is my final question in this go around. In my data-bound forms, I *have* actually written commuter modules to handle various processing needs…This works perfectly for edit boxes, however in edit tables, I get Value1 Value2 on row 1 instead of Value1 in row1 and Value 2 in row2. I have tried a few different properties and the closest I can come is: Value1 Value2 in row1 and Value2 in row2. So I *am* getting closer to a solution but thought some kind soul here could give me a leg up.

Are you converting the delimeters back to @FM/@VM before you try to stuff the edittable? What property do you want to use?

[email protected]

SRP Computer Solutions, Inc.

Mike,

Q#2) What about converting to uppercase while the user is typing? Try with the following code in the edit table's CHAR handler:

$insert Logical

declare function EditCell

SelPos=Get_Property( CtrlEntID, "SELPOS" )

ColNo=SelPos

if ColNo=2 then

Value=Get_Property( CtrlEntID, "CELLPOS", SelPos )

Sel=Get_Property( CtrlEntID, "SELECTION" )

convert @Lower_case to @Upper_case in Value

UnUsed=Set_Property( CtrlEntID, "CELLPOS", Value, SelPos )

UnUsed=EditCell( CtrlEntID, true$ )

UnUsed=Set_Property( CtrlEntID, "SELECTION", Sel )

end

RETURN 0

Here I've assumed it's in column 2 you want uppercase (if ColNo=2 then).

(Some explanation about the programming: Setting the content of the cell returns the cell to overwrite mode. Therefore I use the EditCell function to restore the cell to edit mode. And since the EditCell function destroys the selection (cursor position) I reset the selection after calling EditCell.)

- Oystein -

Hey Don!

Thanks for the response. The Boss being the boss, doesn't really have a clear concept of data collection, so I'm pretty much left to my own devices, so long as I can get the information that he wants. If they'd only learn that Peachtree is only an accounting program, and just barely. lol

The suggestions you made worked very well. POSCHANGED was exactly where I needed to put the actual data upper_case conversion.

As for the other question, carrying over multivalued data from previous records as a default value, I convert @svm to @vm in the variable carrying the data before applying set_property to the table data (I've tried the LIST and ARRAY property, but still get the character separating the 2 values on the first row). I'm game for any property to use, so long as it will put the values into their separate rows in the edittable.

Thanks again for your help!

Mike

Oystein,

Thanks for the tip. CHAR did, indeed, perform the upper_case conversion as the user (me) typed, however it would only accept a single character of data. Naturally, that single character continued to change as long as I typed, but you get my drift. The only change I made to your code was Col=1, which is the column I wanted to convert.

Mike

Mike,

Would you be willing to email me the string of data that you are attempting to stuff into the edittable?

[email protected]

SRP Computer Solutions, Inc.

View this thread on the forum...