To get the info of particulat field, or fillin, or combo etc.

Pavan Yadav

Member
Hi All,
Can anybody help me out in this to get this inof:
I want that in my application if i press some key suppose Alt + D or whtevr....
Then i will get the info of the fillin, filed, combo whrevr the cursor is present that time.

I have to go into the backend/Code to get the info, that from where data is fetch into this.
So, i want a way so that i get this info i.e from which DB field this fillin or field or combo is getting value.
I heard of that there is sort of thing in Mfg/Pro... i want that idea, that genric way to do that.
 

j4n

Member
try this...

Code:
On ctrl-d ANYWHERE
DO:
 Message self:label
     view-as alert-box info buttons ok.
End.

keywords are "ANYWHERE" and "SELF". the rest should be self-explanatory :).
 

Pavan Yadav

Member
My dear friend, this code gives me the label only.
But not the Field info which is updating that fill-in. Or the info of the field where that fill-in data assigns value.
So, i want something in depth of that. :)
 

j4n

Member
Replace ":label" with the information you need then. I just wanted to show you how to create a trigger that works for all fill-ins and how to access the one that fired the trigger.
 

Pavan Yadav

Member
Tht's what i am not able to get ....
Waht to put in place of ":label" to get the field from where that fill-in or combo is getting the value or the field where that fill-in or combo is assigning the value.
 

tamhas

ProgressTalk.com Sponsor
Are you updating Customer.Name or are you updating a local variable which has been set from Customer.Name and which you will then assign to Customer.Name when you finish the screen? If the latter, then there is nothing about the local variable which will tell you about the database field.
 

D.Cook

Member
If the former, check out the following keywords in the ABL reference:
frame-db
frame-field
frame-file

But directly accessing the fill-in widget is a safer option. Check out the ABL reference for the fill-in widget to see a list of all attributes available to you. Note the NAME attribute will default to the database field name.
 

Pavan Yadav

Member
Thanks all,
It could return me the Variable also whcih inturn is updating the DB field. It's ok for me.

Db-field or Variable if it is ....
 

tamhas

ProgressTalk.com Sponsor
It sounds like you are updating a variable, e.g., chName and then following the update you are doing assign Customer.Name = chName. If so, the field being updated has no inherent properties related to the database. Your only option there would be a naming convention which allowed you to determine the DB field name. E.g., ch_Customer_Name could be parsed to Customer.Name.
 

Krishan Gopal

New Member
Hi Pawan,
As j4n suggested in his first code that can provide any kind of information related to DB field(If you are working with DB fields not variables). Tamhas also suggested working with procedure variables you cant get much info.

Below is sample piece of code, I created one GUI window with only fill-in that is Customer.Name and copy following trigger in main-block of the program -

ON F1 ANYWHERE
DO:
MESSAGE SELF:NAME SKIP SELF:TYPE SKIP SELF:FRAME-NAME SKIP SELF:WINDOW:TITLE
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
I think it will solve your purpose, if something else you want to know except this please type your query here!

And yes as D.Cook suggested that also work very well, you can try any one of these depends upon your requirement!
 

Pavan Yadav

Member
Thanks evrybody.....
it's working almost fine.....

Gopal, as u said it's working fine with customer or sort of small application..... but it's nt working with my application in some area...
So i will check out the reason for the same & will query once again....

But, this is what i want only... as per tamhas example...i.e it should give me chname if i am updating it whrough varibale & shoud give me DB field if i am updating it directly... means any of these two...
 

tamhas

ProgressTalk.com Sponsor
Do you understand that, if you are updating a variable, there is nothing at all about the update statement which knows that you are later going to assign the value of that variable to a DB field? In fact, consider an update of a variable followed by logic which then updated one of three different tables or no table at all based on the value of that or another field. How could it possibly tell you. Your only choice here is to make the connection yourself and either apply that knowledge externally or to name the the variable according to some convention, as I illustrated above, that will tell you where the value is headed.
 
Top