Xdialog, Xbasic for Data Entry

[JetLi]

I was curious about the main advantage of using xdialog and xbasic over the point and click to create a data entry form in alpha, I saw a post by one of the Certified Alphaholics, He is suggesting to use xdialog quoting him as "That's what I do, mostly, rarely use forms and never use browses to enter/edit records." What could be the advantage/reason why he said that, and what is wrong with using forms and browses to enter/edit records in alpha? I came to think of this, can we build full, robust and reliable commercial apps with just forms/browses and action scripts in alpha, without using xdialog and maybe using a little xbasic code.?

[Clunes]

Re: Xdialog, Xbasic for Data Entry

Xdialogs allow absolute complete control over the user input as nothing can happen on the form until you(the designer) want it to happen. You can manage this with forms as well, but users, being users, often find the one thing in the design of the form you have not catered for, EG: Save when you are half way through and you really did not want them to save at this point. That said Alpha has the way to do this you just have work out what is best. I use xdialog extensively for adding records, but then use the form to manage chages etc

[jacobr]

Re: Xdialog, Xbasic for Data Entry

Clunes,
I was really looking for what u mentioned above abt initial record saving. Could you pleeease show me some sample codes of that xdialog for creating the records.
I have little clue abt xdialog.

Thanks

Renny

[Keith Hubert]

Re: Xdialog, Xbasic for Data Entry

Renny,

Have a look at Learning XDialog that ships with Alpha. It will open a whole new world for you. Work through all the lessons.

[Tom Cone Jr]

Re: Xdialog, Xbasic for Data Entry

Renny, have you discovered the "Learning Xdialog" database yet? It's in the "learning Xdialog" folder in your Alpha Five program files folder. A number of examples are included, though none do exactly what you seem to be asking for (so far as I can recall.). Lesson 6 "Introduction to Dialog Box Events" is key. After the user supplies inputs they click OK and event fires. Code needs to detect the OK event and then run to enter the inputs into new records in your table.

-- tom

[Clunes]

Re: Xdialog, Xbasic for Data Entry

Below is a sample that creates an xdialog to make a payment. Simply copy and paste as a new code. Take note that ifyou try to save you will get an error as you do not have the tables it will try to save the data to, nr the report it wants to print

DIM form_name as C
if is_object(topparent.this) then
form_name = topparent.name()+".this"
else
form_name = ""
end if
DIM SHARED dat1 as D
DIM SHARED Item as C
DIM SHARED paytpe as C
DIM SHARED cost as C
DIM SHARED qty1 as N
DIM SHARED Tot1 as C
DIM SHARED GST2 as C
DIM SHARED tot2 as C
dim mynum as c
dim tot3 as n
dim tot4 as n
dim ccn as c
dim ccex1 as c
dim ccex2 as c
dim ccname as c
dim cbranch as c
dim bank as c
DIM SHARED varC_resultac as C
dim gstrate as c
sale_type = .t.
paytype = "Direct Deposit"
gstrate = "Current GST rate = " + GST + "%"
DELETE expression_result
expression_result = eval("date()",form_name)
dat1 = convert_type(expression_result,"D")
Item = ""

cost = ""
qty1 = 1
Tot1 = ""
GST2 = ""
tot2 = ""
ok_button_label = "&OK"
cancel_button_label = "&Cancel"
varC_resultac = ui_dlg_box("Add Payment",<<%dlg%
{region}
{font=Arial,10}
Date:| [%DATE;P=popup.calendar(dtoc(dat1));I=popup.calendar%.17dat1!dat1_*];
Description::|{initial_focus} [%mw%.50,3Item];
;{font=Arial,10}

{font=Arial,10}
Payment amount:|{font=Courier,8} [.20tot2!pay_*];
{font=Arial,10}
{region}Payment Type:{endregion}|
{region} (paytype:Direct Deposit!t1_*)
(paytype:Credit Card!t1_*)
(paytype:Cheque!t1_*)
(paytype:Cash!t1_*){endregion};
{endregion};

{condition=(paytype="credit card")}
{region=a}
Credit Card Number: |[.40ccn];
|[4.ccex1] Expiry Month [4.ccex2] Expiry Year;
|[30.ccname] Card Holder Name
{endregion}




{condition=(paytype="cheque")}
{start_pos}
{region=a}
Cheque No: |[.40ccn];
|[30.Cbranch] Account No ;
|[30.ccname] Drawer ;
|[30.bank] Bank
{endregion};

{condition=.t.}


{line=1,0};
{region}
{font=Arial,10}
<*15=ok_button_label!OK> <15=cancel_button_label!CANCEL>
{endregion};
%dlg%,<<%code%

if left(a_dlg_button,5) = "dat1_" then
if a_dlg_button = "dat1_killfocus" then
dat1 = ctod(dtoc(dat1))
end if
a_dlg_button = ""
end if

if left(a_dlg_button,4) = "pay_" then
if a_dlg_button = "pay_killfocus" then
mynum = str(val(tot2),10,2)
tot2 = mynum
end if
a_dlg_button = ""
end if
if left(a_dlg_button,3) = "t1_" then
if a_dlg_button = "t1_killfocus" then

end if
a_dlg_button = ""
end if
if a_dlg_button = "OK" .and. item = "" then

a_dlg_button = ""
ui_msg_box("No description","Must isert a payment description")

ui_dlg_ctl_goto("Add Charge","Item")
end if
if a_dlg_button = "OK" .and. (tot2 = "" .or. Val(tot2) = 0) then

a_dlg_button = ""
ui_msg_box("No amount","Must isert a payment amount")
ui_dlg_ctl_goto("Add Charge","tot2")

end if

%code%)
if varC_resultac = "CANCEL" .or. varC_resultac = "" then

end
end if
dim t1 as p
dim t2 as p
dim q1 as p
dim Global inv_ID as c
dim tranid as c
dim nrec as n
dim global inv_ID as c


t1 = table.open("invoce",FILE_RW_SHARED)

t1.enter_begin()
t1.Date = dat1
t1.Client_id = var->lits1

t1.Profile_id = "1"

t1.Sale_type = .t.
t1.Ccard = ccn
t1.Ccname = ccname
t1.Ccexm = ccex1
t1.Ccexy = ccex2
t1.Chqno = ccn
t1.Drawer = ccname
t1.Bank = bank
t1.Accountno = cbranch
t1.enter_end(.t.)
t1.refresh()
t1.fetch_last()

inv_ID = t1.Invoice_no

t1.close()

t2 = table.open("sale_summary",FILE_RW_SHARED)

t2.enter_begin()
t2.Invoice_no = inv_ID
t2.Client_id = lits1
t2.Sale_date = dat1
t2.Credit = tot2
t2.Item = item
t2.total = tot2
t2.Btype = paytype
t2.enter_end(.t.)

t2.close()
DIM object_name as C
object_name = ":"+"Client_details1"
DIM varP_Object as p
'Get a pointer to the specified object
varP_Object = obj(object_name)
'Check if the specified object exists
if .not. is_object(varP_Object) then
ui_msg_box("Error","The object '"+object_name+"' does not exist.",ui_stop_symbol)
else
'Can only resynch data in View mode, so save record first to be sure that layout is in View mode.
varP_Object.Commit()
varP_Object.Resynch()
varP_Object.Refresh_Layout()
end if

query.filter = "Invoice_no = alltrim(Var->inv_ID)"
query.order = "recno()"
'replace variables in the filter with their actual values
query.filter = convert_expression(query.filter,"VE")



:Report.Preview("receipt",query.filter,query.order,.t.)

[Mike Wilson]

Re: Xdialog, Xbasic for Data Entry

Since it's likely me that Jetson is referring to regarding the statement about xdialogs, I guess I'll chime in. But I can't add more than Mark has said and exemplified with a great example!! You need to change GMT to a number in the script to run it in IW, but it really shows the power well of xdialog. It is a fabulous tool for a developer to steer the user through a process in just the manner you as a developer wish to make happen. And it all happens with the capability to accomplish all validity checks and value transformations and matching data events, etc, etc BEFORE a commitment to the table(s) occurs. Beautiful tool!

[CALocklin]

Re: Xdialog, Xbasic for Data Entry

... never use browses to enter/edit records." What could be the advantage/reason why he said that, and what is wrong with using forms and browses to enter/edit records in alpha? ...

Note that whoever said that apparently did NOT say "never use forms and browses" - just "never use browses". Weird things happen when trying to use a browse to enter data. At least, this is true for an embedded browse (see below). This was the problem that caused so many developers to complain about the browse many years ago. Unfortunately, Alpha either didn't or couldn't fix it and even the "new browse" didn't fix it - at least not initially. Maybe the issue is fixed now but I doubt it. They weren't fixed in the "new browse" (the only one available now) when it was initially released and I gave up on it so long ago that I don't even check anymore. (I still don't think they actually understood what we were complaining about.)

DISCLAIMER: These problems were so bad and lasted for so long (starting in v5 as I recall) that I haven't checked since shortly after the "new browse" was released in v10.5 - at which point it was still an issue. Maybe the problem has been fixed now.

Here's what I've seen that stopped me from allowing browses to be used for data entry. There is NO problem when the browse is, for example, 5 lines high and there are never more than 5 records in the browse. However, once the browse has more records than lines, arrowing down to the next record can sometime cause the user to end up seeing the data from the "previous" record even though he is actually in the "next" record. When that happens, you might get lucky and have a user who starts scrolling around to find out what happened and that person will eventually figure out what record he wants to change and do it correctly. On the other hand, some people just "fix" the data (in the wrong record) and end up with a major mess.

It might have been fixed now that scrolling down causes the browse to jump the "next" record to the middle of the browse when arrowing down past the bottom row. Unfortunately, that "feature" doesn't make things much better because people are confused by the weird jump from "bottom line" to "middle row" instead of "top row". (In my opinion it's a very strange feature - which is confirmed by the many complaints from my customers. I have no idea why Alpha did it and, like so many other "improvements", I wish they would have made it an optional feature so I could change it back to something that won't confuse my users. If someone knows how, please let me know.)

So, until I know absolutely, positively, indubitably, and without question, that this problem has been solved, I will NEVER allow users to enter/edit data in an embedded browse. (And I never allow users to work in a plain browse. As far as I know, a plain browse works fine but you can't reasonably put help buttons, close buttons, find buttons, help/descriptive text, other fields, etc. on them to "dress them up" to work well for users. Using a form with an embedded browse allows a lot more flexibility when it comes to user-friendly design.

I will sometimes do data entry in an embedded browse myself but only because I know what to watch out for. I never allow users to do it.

There's also the fact that some users just seem to have a hard time following one line all the way across the screen. For these people it doesn't matter if the browse works perfectly or not. Consequently, even if the browse is fixed now, I still wouldn't trust most users enough to let them use it for data entry.

[Ted Giles]

Re: Xdialog, Xbasic for Data Entry

CAL, my experience is not the same as yours when using a Browse, but maybe because I use Saved Browses with all sorts of lookups on the content - and in a Tabbed Form too.
Do you have the same problem with saved browses?
Mine behave correctly as far as I've tested - up to 30 lines.

The reason I do so in an invoicing situation is to enable an easily visible history of line items on the invoice with a running total. I can't see the point of displaying another form just to enter a line item and then going back to the browse display.

The only awkward bit is that [Key Esc] will exit an incomplete line, but I couldn't get [SYS_SEND_KEYS("{ESC}")] - effectively Cancel Changes as that doesn't work either in a Set - on a button to do the same. Had to use Delete as the record has focus.

[Ted Giles]

Re: Xdialog, Xbasic for Data Entry

Below is a sample that creates an xdialog to make a payment. Simply copy and paste as a new code. Take note that ifyou try to save you will get an error as you do not have the tables it will try to save the data to, nr the report it wants to print

"Variable GST not found" Mark.

[Ray in Capetown]

Re: Xdialog, Xbasic for Data Entry

"Variable GST not found" Mark.

I havent tested it Ted, but looking at the code: Change GST to GST2 in the line

gstrate = "Current GST rate = " + [COLOR="#FF0000"]GST[/COLOR] + "%"

I would really like to support Ted's view regarding edit in embedded browses. I found V8 was still pretty unstable.
Does anyone else have instances in the latest V10.5 revision that their users get incorrectly attached child records or other anomalies described by CAL? And if so any ways found to lock this down?

I have the demand from users, because they are comfortable and quick with entering data in tabular form and want often to click a field few rows away to edit just that field and return to the line - without having to first complete a dialog for the line they're on then get another, go down to the field to change, save, and then another dialog to get back to where they were.
Example - commonly in a live order capture session with a customer - "I want 40 of these and then 12 of those" and then "just change the 40 of those to 20 and give me another 20 of another" ... kind of thing.

[JetLi]

Re: Xdialog, Xbasic for Data Entry

Note that whoever said that apparently did NOT say "never use forms and browses" - just "never use browses". Weird things happen when trying to use a browse to enter data. At least, this is true for an embedded browse (see below). This was the problem that caused so many developers to complain about the browse many years ago. Unfortunately, Alpha either didn't or couldn't fix it and even the "new browse" didn't fix it - at least not initially. Maybe the issue is fixed now but I doubt it. They weren't fixed in the "new browse" (the only one available now) when it was initially released and I gave up on it so long ago that I don't even check anymore. (I still don't think they actually understood what we were complaining about.)

DISCLAIMER: These problems were so bad and lasted for so long (starting in v5 as I recall) that I haven't checked since shortly after the "new browse" was released in v10.5 - at which point it was still an issue. Maybe the problem has been fixed now.

Here's what I've seen that stopped me from allowing browses to be used for data entry. There is NO problem when the browse is, for example, 5 lines high and there are never more than 5 records in the browse. However, once the browse has more records than lines, arrowing down to the next record can sometime cause the user to end up seeing the data from the "previous" record even though he is actually in the "next" record. When that happens, you might get lucky and have a user who starts scrolling around to find out what happened and that person will eventually figure out what record he wants to change and do it correctly. On the other hand, some people just "fix" the data (in the wrong record) and end up with a major mess.

It might have been fixed now that scrolling down causes the browse to jump the "next" record to the middle of the browse when arrowing down past the bottom row. Unfortunately, that "feature" doesn't make things much better because people are confused by the weird jump from "bottom line" to "middle row" instead of "top row". (In my opinion it's a very strange feature - which is confirmed by the many complaints from my customers. I have no idea why Alpha did it and, like so many other "improvements", I wish they would have made it an optional feature so I could change it back to something that won't confuse my users. If someone knows how, please let me know.)

So, until I know absolutely, positively, indubitably, and without question, that this problem has been solved, I will NEVER allow users to enter/edit data in an embedded browse. (And I never allow users to work in a plain browse. As far as I know, a plain browse works fine but you can't reasonably put help buttons, close buttons, find buttons, help/descriptive text, other fields, etc. on them to "dress them up" to work well for users. Using a form with an embedded browse allows a lot more flexibility when it comes to user-friendly design.

I will sometimes do data entry in an embedded browse myself but only because I know what to watch out for. I never allow users to do it.

There's also the fact that some users just seem to have a hard time following one line all the way across the screen. For these people it doesn't matter if the browse works perfectly or not. Consequently, even if the browse is fixed now, I still wouldn't trust most users enough to let them use it for data entry.

Oh my goodness! What a frustration, I have used almost embedded browse in my first app but it's not yet finished, and for what I know, the users will not only encode 30 lines in the embedded browse, it could be 40 or more, we turn to alpha as our database development tool because of it's simplicity to create a data entry form of one to many relationships of tables, but now, a great frustration slammed into my face.I feel like heaven fell on me,What then could be the easiest and the simplest way of saving data into a detail table in a one to many relationship?I used browse because it was used in the alpha sports sample.

[JetLi]

Re: Xdialog, Xbasic for Data Entry

Ray, A huge time saver for a developer isn't it? I was just wondering, how come alpha has been used for a long time but browse control is still unstable, what then did alpha experts here at this forum suggest to you, maybe you have some PM from them that you can share?Xdialog as the experts say but it contradicts the main feature of alpha that is to create database apps RAPIDLY, if we use xdialogs then it will be called RAPID if a user will really invest time learning it, I hope the browse control will be fixed.

[Keith Hubert]

Re: Xdialog, Xbasic for Data Entry

Jetson,

Xdialog is another tool in your Alpha toolbox. The advice Cal has given you is from years of experience. I value his advice greatly. It is to give you another light on how to make the best use of what is available. When you started using Alpha and came on the forum, no one here knew how many lines in a browse you would be wanting to enter. A few lines would not be an issue, but 40-50 could be when you are trying to enter data and scroll before a record is saved. Good use of a dialog box will give you as a developer, more control over how your users use the application. I'm sure you would want to make data input as tightly controlled as possible to help prevent mistakes.

Best way to think of a browse is a window to a whole lot of data that has been entered either through another form or a dialog box. These things you learn from experience. Learning something new about database development is not a "slap in the face". You did not learn to run before you could walk, did you?

[Mike Wilson]

Re: Xdialog, Xbasic for Data Entry

A house has many openings to the outdoors. There are chimneys, roof vents, windows and doors. Usually there are many windows and certainly it would almost at any instance be most convenient to get to the outdoors through a window. And certainly windows are sometimes demanded to have capabilities for egress. But that's not what a window is for. You can use it as a vehicle to move to and from the outdoors, but it's fraught with issues. There are other objects in your house that are meant and designed for egress. Just look at an embedded browse as a window, and work with it for what it is designed to do best, and you will save yourselves a great deal of grief, and get on with things. That's what Cal and other experienced developers have done. That is what I have done.

Yes, xdialogs do take a fair amount of time to learn the nuances and controls. But once you have a basic understanding of them, in my experience, it takes me less time to generate a powerful xdialog than it does a form. Because it is code, and you save code in your code libraries. I have 4-6 pre-written xdialog codes that have some different features. I select one of them, tweek the code a bit, and you have data gathering and entry directly to/with tables, that don't even have to be part of the set being worked on, with control and certainty. Even if the embedded browse "window" could flawlessly provide for data entry, I don't think I would go back to try and use it.

BTW, I wrote in post #7 that in Mark's dialog code, that converting the GMT variable to a literal number would make it run.