Still problems with xdialog

[crimmelcp]

can anyone show me how to refresh the attached xdialog
It writes to the trace window fine but I cannot get it to refresh the xdailog.

thanks
Charlie Crimmel

[CALocklin]

Re: Still problems with xdialog

Interesting. I learned of another quirk today. For some reason, doing this by calling a function causes the form not to refresh. I added an xbasic_wait_for_idle() and fixed the problem:

LookupCustomer(local_variables())
xbasic_wait_for_idle()

Personally, I wouldn't do it this way at all. See my response to your other xdialog question where I use a lookupc() function to get all the values with one lookup then parse the result. (I just posted it a few minutes ago so maybe you haven't seen it yet.) I've tested this in the past and that method is MUCH faster than opening the table, searching the table, getting the data, and closing the table. It's even faster when you consider the additional time required to run it as a function. Even though you have to parse the results, it's still faster - and it only takes a few lines. In fact, I think these few lines are easier to read/edit than the multiple lines required in your function:

info = lookupc( "F", v_customer_id, "trim(lastname)+' | '+trim(firstname)", "customer", "Customer_I")
v_lastname = word( info, 1, " | " )
v_firstname = word( info, 2, " | " )


As a general rule, you should NOT have to refresh a regular xdialog. If you do, something else is probably wrong. Once the variable has been changed, the change should immediately show up in the field. In this case, there was apparently a timing issue causing the problem. Also, ui_modeless_dlg_refresh() can't be used to refresh a non-modeless xdialog. (Is there a way to refresh a regular xdialog???)

Later:
I see there is a UI_DLG_REFRESH_TARGETED() function but I've never had to use it as far as I can recall.

[MikeC]

Re: Still problems with xdialog

Cal,

As a general rule, you should NOT have to refresh a regular xdialog.

Really!!? I have been meaning to ask on the board here for a while now regarding how to refresh an xdialog list box after adding more table data via the xdialog. I have tried modal and modeless refresh functions and neither do a darn thing---I mean it is like I never added the refresh.

All I am doing is adding a path to a field in a table with the xdialog. I want the newly added pathway to be immediately shown instead of having to close the xdialog and reopen it to see the change.....same is true when a record is deleted from a table....have to close the xdialog and reopen to see the change.

If this should not be an issue then I will try and get something as a sample attached....thing is, I have to keep reworking my xdialogs between versions 8, 9, and 10 for various issues and must have forgotten something in the one sample I could have used....but it no longer works as it did.....hate having 3 sets of code for the same thing!!!! :)

[CALocklin]

Re: Still problems with xdialog

I'm pretty sure I've update list boxes without needing to refresh them but maybe you are doing your list boxes differently than I am. (I hate keylist_build so it's definitely different if you are using that.)

If you have a sample, post it and I'll take a look.

[Mike Wilson]

Re: Still problems with xdialog

I have been using something like this. I got it from:

http://msgboard.alphasoftware.com/al...ghlight=dialog

There is also some other code on this message board from several years back that Peter Wayne wrote that has a refreshing dialog other than that one . I believe it had something to do with stock symbols, or something close. I try and hunt it down.

[MikeC]

Re: Still problems with xdialog

Sorry Cal and Mike for just now getting back to this---never thought I would have such a hectic week!!

I delayed opening the thread as a reminder to get back to this so I am just now seeing Mike's example and will check it out tonight...thanks for your time on this Mike....and also to whoever takes a look-see into my issue.

Here is my sample--I have two xdialogs that need to auto-refresh..one adds records and the other (in this sample) deletes records. Neither one refreshes unless closed and reopened.

I included 20 records that can be deleted---gives you 19 tries to figure out why it is not refreshing before having to copy/paste again! Shouldn't need more than that right!!!? :)

[MikeC]

Re: Still problems with xdialog

Hi Mike,
Just took a look at your example---I can see where what I asked could be misconstrued. I mean I have a refresh issue when I delete something directly from the xdialog box. It will persist until I close and then reopen the xdialog.

[CALocklin]

Re: Still problems with xdialog

Mike,

The secret - You just needed to rebuild the lookup list in the %Code% section after deleting the records. That's all the "refreshing" you needed to do.

One key to making the list easier to rebuild was to eliminate the use of an array for the display list. All Alpha's samples use an array but it isn't necessary and makes working with things much more difficult. I only use crlf() lists anymore. (I try to believe that all that complexity is needed because of the various possibilities with genies but sometimes I wonder.)

In the attached zip file there are two new scripts [modified with my own free script_formatter routine which means that the spacing and capitalization is also different]:

Xdlg_list_Cals_comments - shows all the comments I made along with the changes. Many of them are just suggestions and do not affect the finished result. Consider my comments then do what works for you. All the comments and remmed out lines make this look more complicated so....

Xdlg_list_simplified - I took all my comments and all the remmed lines of code out of this one so it's easier to read.

Also, I didn't mention it in the script comments but other reasons I like putting the button text directly in the button is:
1. With the button text in the button itself, I don't have to scroll all over the place to find out what the button text is -especially if I want to consider changing it.
2. With the label in the button itself, it's easier to fit multiple buttons like this on one line so you can play with the spacing more easily. Especially when using Alpha's long variable names. (Unless, of course, your button text is really, really long but even that might be nice to see while you're working on it.) When you do it this way, the button text is also the event name when you click it - no need to define a separate event name unless you really want to. (I've been known to use a separate event name when the button text is really long. For example, if the text is "Yes - I really want to delete these" then the event name might be set to "OK" like this: <Yes - I really want to delete these!OK>)

[MikeC]

Re: Still problems with xdialog

Thank you Cal.

Most of what you saw in the xdialog was generated at first obviously by Action Script and then modified by me (and someone else even prior a small amount). I have taken in quite a bit of your comments already from many of your prior posts regarding xdialog but your extensive comments here for sure reinforce them. I do try and experiment to eliminate extraneous script and your suggestions definitely have helped (will help).

I still cannot seem to modify my existing code to refresh, but yours does....will have to check it out a bit more.

But can see now that I really was missing something (and had tried simply obtaining new records to populate but even now it does not work---with my original script). So the xdialog really does not automatically refresh...more code does have to be added.

Late night again--best to look closer in the new light of tomorrow am thinking.....

Thanks again Cal.

[Tom Cone Jr]

Re: Still problems with xdialog

One key to making the list easier to rebuild was to eliminate the use of an array for the display list. All Alpha's samples use an array but it isn't necessary and makes working with things much more difficult. I only use crlf() lists anymore. (I try to believe that all that complexity is needed because of the various possibilities with genies but sometimes I wonder.)

Cal, it can be useful to keep the array related code in some cases. There are times when you may want to manipulate the displayed list without refetching records from the table. For example, if you wanted the user to be able to sort the list from Z..A and then back to A..Z that kind of thing can be done more easily in the array than in the list. If you do it in the array then you simply rebuild the list without refetching the same records from the table again.

[csda1]

Re: Still problems with xdialog

Hi Tom,

For example, if you wanted the user to be able to sort the list from Z..A and then back to A..Z that kind of thing can be done more easily in the array than in the list. If you do it in the array then you simply rebuild the list without refetching the same records from the table again.

In general, it is faster to init an array, sort the array and dump it back to a list than to sort the string (In Alpha anyway). If you don't have to go back to a list (except maybe for the final output) it is even faster.

Arrays can also keep data separate without worrying about field separators (sometimes a big issue!)

I'll generally switch between arrays, lists, pointers and collections depending upon

• whether they meet the need (e.g. collections are not case sensitive in the key)
• which one is fastest including any associated overhead
• what built-in methods/functions they have and their speeds
• what is most flexible (e.g. arrays are less dynamic in size than lists, which you need only append to.

[csda1]

Re: Still problems with xdialog

Hi Mike,

So the xdialog really does not automatically refresh...more code does have to be added.

I have looked at your code xdialog_refresh.zip. This XDialog code fetches data from a table, formats it for XDialog, then stuffs it into an array, that it then displays with checkboxes. The delete event code for it deletes the associated table's data, but the array that is being displayed in the XDialog window was not changed, so it is still the same display of the array.

There were a couple of choices here.
1. You could delete all selected elements in the array to correspond with the table delete to keep them in sync.
2. You could get all new values from the table after the delete, format them and re-initialize the array with the data.

UI_MODELESS_DLG_REFRESH() will refresh the current data in the objects being displayed (if they don't automatically - in most cases they do, but there might be exceptions, particularly in lists/arrays), but only if those objects actually have changed.

In your case the displayed array never changed, until you ran the XDialog again.

A side effect of UI_MODELESS_DLG_REFRESH() will be that the list/array current line will be what ever that return value is now set to (if you changed it) and will be the top line if that section list/array object is scrolled due to size. In other words, if you could see items 15 to 35 and 25 was selected, after the refresh you would see 25 at the top all the way to 45

[MikeC]

Re: Still problems with xdialog

Ira,
I indeed did attempt what you stated last night...

1. You could delete all selected elements in the array to correspond with the table delete to keep them in sync.
2. You could get all new values from the table after the delete, format them and re-initialize the array with the data.

with no results at all.....but then it was fairly late and will revisit this today to figure it out as I must have made an error obviously!

Thanks for your explanation.

[csda1]

Re: Still problems with xdialog

Hi Charlie,

can anyone show me how to refresh the attached xdialog
It writes to the trace window fine but I cannot get it to refresh the xdailog.

I've started to look at your code. Many things are wrong with it.

You are trying to use Global variables, but I see a whole block of code that looks like this

dim Globalv_FIRSTNAME as C
dim Globalv_LASTNAME as C

but should be like this

dim Global v_FIRSTNAME as C
dim Global v_LASTNAME as C

so later in the function LookupCustomer, all of it's references will be to a Local variable (since no Global variable of the same name exists), which will be valid only within the LookupCustomer function.

There are other issues (e.g. no save of change data), but the above is #1 in the issues.

[crimmelcp]

Re: Still problems with xdialog

Thanks Ira:
I had corrected everything and all seems to be workin fine

Thanks
Charlie Crimmel