Changing Fields in a View 1

[k2a]

Hi all,
Could someone help me with the following programming problem?

In a form I have 2 identical list boxes (LB1 + LB2). LB1 displays some fields of a record from
the content of a view while LB2 is empty. With a dlbClick on any line in LB1 copys this line to
previous empty LB2. A dlbClick on a line in LB2 removes that line. This works fine.

Now I want to set the field "hide" in the view to TRUE with a command button cmdHide of all
lines from LB2. The view itself has a filter to show only records if the hide is False. So
after changing the "hide" fields and after a REQUIRY the lines shown in LB2 should disappear
from LB1.

However, to realize that I have some difficulties. Does anyone have an idea?

Klaus

 

[Julio_MGM]

I don't know if i understood what you where saying but, why don't you work with one array, and you fill the 2 listboxes with the data from that array.

(value_display, show_lb1, hide_lb1, selected_lb1, show_lb2, hide_lb2, selected_lb2)

 

[Olaf Doschke]

Let me guess you defined a where clause in the view WHERE hide=.f.?

A requery of that view would only reduce the records shown in the listbox, when you go back to the table and set hide there. You shouldn't as that changnig the hid status for all users.

Simply delete the record from the view, if you don't want to display it.

And design your view to be NOT updatable, because you don't want the selection of one user to become updated in the source DBF table, do you?
Also a requery of the listbox isn't automatically a rerquery of a view. You're having wrong ideas about several concepts, here.

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[k2a]

Hi Olaf,
>> A requery of that view would only reduce the records shown in the listbox. <<<
That's exactly what I want to achieve. The final result of the view is not transferred back to
the original table, but goes into a completely different table.

My request points more to how to achieve that. Locate a line in LB2, find this line
in LB1 and modify then the view's hide field. After that transfer the modified view into a
new table.

You are correct in saying "You're having wrong ideas about several concepts, here."

Klaus

 

[Olaf Doschke]

You're cutting my words, that's not what I am saying.

A view with a WHERE HIDE=.F. clause will not work unless you also first change the table data.

You don't work with a hide field a list box can't be hidden by rowsourcetype alias. You simply lilst all not deleted records. Unless you have a routine that 1. clears the itmes and then only adds the records as items that have hide=.f.

But then you don't have a listbox that has a cursor as rowsource.

You SET DELETED ON and DELETE the rows you don't want to see, you don't work with a HIDE field.

OR you work with a HIDE field and only query the records with HIDE=.F. then change view records to HIDE=.T. that doesn't let them disappear, they're already queried, you don't change the view records to what they would have been if the table had HIDE=.T. records in them. A WHERE clasue isn't the same as a FILTER, A WHERE clause filters data, but only at the time of the query.

If WHREE would work like that, you couldn't change view data in respect to the conditions of the WHERE clause originally applied to find them.

The HIDE field as defined in the DBF only helps you for your initial population of the listbox. The only thing that removes a row from a listbox with the alias rowsource is to DELETE that row and as your view does not write back to the source DBF you can do that. You wouldn't necessarily need a view for that, a query INTO CURSOR xyz READWRITE would also do that, but that aside, no need to change that.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[k2a]

Hi Olaf,
thanks for your the detailed answer. First off all, I had to digest what you reported and must confess that I did not get it all. However, one thing seems to be clear now my approach probably will not work the way I thought.

In the meantime, I also considered a cursor solution, but that seems to be too complicated for me and will not have the flexibility of a view.

But what do you think of the idea to create a temporary table TEMP with the same data as that of a view and create a view from this TEMP table. This would give me the flexibility of a view and could change the TEMP as I want to. The source data remain also untouched.

Would this approach be possible?
Regards, Klaus

 

[TamarGranor]

There are various versions of a two-column mover around the VFP community, so no reason to build your own. I use one based on the one in "1001 Things You Wanted to Know about Visual FoxPro"; I made some changes to make it work better for me.

There's also one in the Solutions Samples that come with VFP.

Tamar

 

[Olaf Doschke]

Tamar is riught. The only reason to roll your own is you'll know how ir works.

As I said there is no need to change from view to cursor. (I dont't see what's less flexibkle, but that aside).

No, the essential thins is once you have the view queried and DON'T change the source table (as per your answer your view isn't an updatable view writing back to the table), a REQUERY of the view itself will just reset any changes you made to it, so that's useless. A listbox.requery will just refresh the listbox items, but listbox items always are all view records, no matter if they changed there hide field or not.

So as I said, the solution is to NOT work with such a field, but simply DELETE the one record you move.

You don't drive two listboxes with one cursor, you drive two listboxes with two cursors (or views, views ARE cursors, just "view cursors").

You can also do that, but then you write a routine that uses the listboxes with their itmes array and fills both from the cursor, depending on the flag adding it to one or the other listbox.

Or you use the view as rowsource but also SET FILTER TO Hide=.t., but that also will only work for one listbox. the other will need SET FILTER TO Hide=.F. and you can't have both filters set at the same time, so you'd need two cursors.

Don't get confused, I was not talking of one solution, but 3 or 4. Just get clear what the listbox does. It displays all records of a workarea in that rowsourcetype mode. You can shrink that by the view WHERE filtering initiall, but their visibilty only changes when you remove them through DELETE or SET FILTER and DELETE is the simpler option, isn't it?

In the moment you add an item to the other listbox, you are at that record, so all you need to remove it from the source listbox is to DELETE it. DELETE IN listboxviewcursoraliasname. or if it's the active workarea just DELETE. And then listbox.requery. Of course, after you copied this record to the other listbox as record of another cursor or via additem.

How to go about the final selection is up to what this target listbox uses and what you use to populate it.

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[k2a]

Hi Tamar,
Of course, there are different ways to move data around. However, the mover is not my problem, but changing the moved data afterwards is what I want to achieve.

Klaus

 

[TamarGranor]

My version bases the two lists on arrays. I use code that runs when the user is done to then reflect that back to the source.

Tamar

 

[Olaf Doschke]

I don't know what's your problem, you act on views like you act on DBFs with SQL (INSERT UPDATE DELETE) or xBase Code (APPEND, REPLACE, DELETE).

Is your problem getting back to the original records? Either you make your view(s) updatable or at least have the primary key in the view data, so you can finally scan through the selections or iterate the selections array in Tamar's case and SEEK the record you want to go back to manually. Or populate further tables with child records or whatever you need to do.

Data manipulations are the base of everything. As far as I know, your level of knowledge of VFP is rusty and about legacy versions, you will at least know the xBase way of dealing with data.

Is your difficulty really only about the concept of a list of records instead of a single record you can simply maintain by keeping the record pointer at it? Is it really about not knowing why primary keys are of such immense importance even for maintaining data of a single table without any child tables pointing to it, to have a reliable way of getting back to the record you came from via SEEK than via GOTO to memorized record number? In fact, even if you avoid the primary key concept as long as you don't pack DBFs you can also go back via GOTO reno. It is even faster than SEEK, as finally SEEKS using an index find a leaf node that has a record number and then GOTO that record, GOTO and the constant length of records of DBFs are the core ingredients of how GOTO is a fast way to get to the record via FSEEK in a DBF via the simple offset formula of HEADER()+recno*RECSIZE(). That's what the Foxpro runtime is making use of if you GOTO recno.

Is it that you don't know how to have the record number or ID of records in the list box cursors? Is it not knowing the list box just displays field #1 but your cursor can have record number or id in field 2 and any other metadata you need in further fields? Is it really that you think of limitations like list box cursors only having one field, which is only existing in your imagination?

You don't show any code you already have. You are very vague about your goals and what it is you want to achieve. The last posts you made suggest that the open problem you still have is not about the visibility of records in one of two list boxes involved in a construct we usually call a mover control? Then what really is the problem?

Is it us being too blind about novice problems because to us the ways of Foxpro are too clear? I don't know how to help you. But at this stage, you're not getting forward with your questions because I think you lack the foundations to even ask questions we can make something of and I'd suggest you go to Hentzenwerke and find some beginner level books on Visual Foxpro. They're all older than 10 years, but so is VFP9.

Or step back not just one step. Your overall goal is to achieve some application, isn't it? You're starting off using your rusty knowledge of legacy Foxpro. You reached out to me for help, but I already told you I'm too busy with projects to work even hired, then why don't you step back of it even more, take your overall goal more serious and remove yourself from the programming of it, look out for a software developer of any programming language and not just FoxPro experts. Today software is written for the internet in ASP.NET (C#) or PHP or Python or Java or for the desktop still also in JAVA or C/C++/C#. VFP is a dead end and when the application is of importance to you and you do start from scratch, almost, the porting of data to MSSQL or MySQL is the least problem and you find much more developers in more modern worlds of software development.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[k2a]

Hi all,
Meanwhile I solved my problem to change the source table using a view. In retrospect, the solution was much simpler as I thought it would be at the beginning.

After filling the LB2 with all items from LB1 which should be hided and then run the routine cmdHide from the form. This routine grabbed the items in LB2 moved the primary keys into an array, looped through this array, located the primary key in the source table and changed the hide field to true. The final requery command corrected the view.

However, I need to make much more changes to the underlying table than just changing the hide fields. So that’s why I don’t want to make those changes on the source table itself. My idea is to create a new table with the same content of a view to work with. I think it can be done with the gather and scatter commands but will first check the forum for any clues.

Klaus

Olaf,
In your last post you are getting very personal there. It is very interesting to know what you think about me. Thank you for all the many recommendations and advices. But now let me give you also a good advice, simply ignore my questions here in the forum. Then you will not waste time answering stupid questions from my side. And listen, let the community here in the forum decide if they answer questions from less qualified VFP users. If there are no reactions then it is time to go.
Bye

 

[Olaf Doschke]

Klaus,

it was and is just meant as good advice. Your solution proves you don't get the points I was making. If you really want the changes to happen in the LB1 view, then make them there, going through the source table and having a hide-flag there, which needs to be set so a requery finally removes those records from the LB1 view, well. you can DELETE there.

Your usage of the backend table for temporary data related to one user's session renders this unusable for multiple users. The actions/selection of one user will reflect as ghostly actions to a secondary user. And even if you say this is for a single user application, such flags have nothing to do in the persisted data.

So, in the end, yes, it is very personal and very demotivating advice, but in the best sense of the overall objective. I think your time is better spent on just concentrating on architecting what you want and have someone else more experienced execute this for you.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name