When SELECT doesn't select!!

[tacs]

I think this could be a good one. I have certainly never seen it before so if anyone has could they help please.

First of all, I am looking at someone elses code and so that won't help. This is a form with a grid on it which, when double clicked, should go off, create a readwrite cursor using a sql statement, select the cursor add some data to it and then go off and run a report. I have also seen this here on another form as well, but I'm sure this will do as a starter for ten.

Anyway. The sql certainly creates the cursor with the desired records in it so that's fine.

The form just doesn't seem to select anything, either this cursor or an actual table and SELECT() always returns 1.

SELECT tablename doesn't work, neither does selecting the workarea you get by nSEL=SELECT(tablename) and then using SELECT(nSel).

I have thought about the environmernt and ASESSIONS() tells me there is only 1 session running so it should be visible, you CAN select it if you stop the form and run the command in the command window. If I step it through the debugger it works perfectly so I am a bit confused now. Any help will be gratefully received. Thanks.

 

[Mike Lewis]

Tacs,

If I attach this as a JPEG will it show OK here? I can put it on a web site to get the URL.

If the JPEG is on a website somewhere, you can insert an tag into your post. That way, the image will appear in the post. Example:

[code]
[ignore]
[img]http://www.mywebsite.com/images/screenshot.jpg
[/ignore]
[/code]

However, I'd ask you not to do this unless it's really necessary to explain the problem.

The trouble is that, if the image is wider than the message area, the entire thread becomes wider, which means we have to use the horizontal scroll bar to read the text, which makes the whole thread difficult to negotiate.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Tacs, the behaviour you see can be explained, as you replace in a fieldname the grid recordsource may not have, VFP concludes you mean another alias. It only seems to work, but in that case also the grid, if it has focus, determines the current workarea. The debugger is not out of line. It's simple fact the grid, when it has focus, determines the active workarea. Putting code in form's double click event does not move focus, the form is no control, therefore the assumption, the grid is to blame now seems the most probable to me. It's only another object being capable to get the focus, that will help here.

Finally, a button "PRINT" would be the right thing to SELECT the alias you want to print and do the REPORT FORM. Or, if that should be triggered by some other means, a textbox visible, but with .left =-1000 or something making it off the visible form, will be able to hold the focus from the grid, if you do Thisform.Textbox.Setfocus()/ SELECT printalias/REPORT FORM or /INDEX ON ...

Bye, Olaf.

 

[tacs]

OK, thanks again guys.

I won't link the image in then. I'll try your suggestions in the morning and let you know what happens.

 

[tacs]

Well, I put a command button on the form and copied the text from the double click event into the click of the button. I paused it immediately before running the report and it worked right away. Just as a check I ran it again and the grid double click doesn't select the cursor I need for the report, but every time I ran it and hit the command button it works fine.

I had my doubts I have to admit, because the table that it always sat on was not the table used to populate the grid, but for what ever reason it does work consistently now.

Thanks very much for all your efforts.

 

[tacs]

Just for completeness.

After putting a button on the form and copying in all of the text from the double click of the grid, I replaced the double click text with :

thisform.command1.click

This also seems to work quite happily.

 

[Mike Lewis]

Tacs,

Glad to hear you've got it working. You've confirmed what we suspected about the grid. Grids can be a bit peculiar at times, especially when it comes to work areas and aliases.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Well,

calling a click event is quite different from it being triggered by a real click. Because the main point is, that the focus is moved off the grid, to the button. If you call the button click from the form.doubleclick you won't move the focus from the grid to the button, you merely call code and it won't make a difference if it's called or you do it directly in the form.doubleclick.

It's kind of a wonder that works. But as you also say the other alias that was always selected was not the grid's recordsource, so I now suspect it really had nothing to do with the grid behaviour but was another bug in your code you now solved somehow.

Bye, Olaf.

 

[tacs]

Thanks Olaf. I have no clue what makes this work, but nothing has changed in the code. The entire piece of code was picked up from the grid double click and placed in the new print button's click event.

The data source for the grid is a cursor created from the table it always refused to move from (which was workarea 1 and may or may not be a coincidence) along with several other tables linked in using a SQL string in BeforeOpenTables.

As I said, no changes have been made to the original code apart from which event runs it.

I would like to say thanks to everyone that contributed to what was causing me a real headache.

 

[Olaf Doschke]

Okay, now you finally confuse me again, because earlier on you talked about form's doubleclick and not grid.doubleclick():

The problem seems to occur within the double click event of the form.

Well, as you say the alias the SELECT didn't move away from was the 1st alias in the datasession, perhaps you have the wrong assumption about what the grid is bound to. The grid, if it does not have a recordsource set at design time, will take the selected alias as it's source at runtime.

Bye, Olaf.

 

[tacs]

Sorry Olaf, I didn't mean to cause more confusion that there already seems to be with this little problem. The code that was being run sat in the double click event of a column1.header1.text1 in the grid.

In the IDE at design time the RECORDSOURCE of the grid is set to a cursor that was created by a SQL command that linked several tables inlcuding the one that was constantly left select by double clicking on the line/column of the grid. RECORDSOURCETYPE is set to "1. Alias". Each of the columns has a CONTROLSOURCE set to alias.fieldname so there's no real question about where the data should be coming from.

Thanks anyway Olaf

 

[Olaf Doschke]

You could clear thing up by using the class browser to export the form in code:

Choose Tools->Class Browser from the menu (also, if it's an SCX form)

Choose File->OPen or the open button from the toolbar to open the scx or vcx with the form. Depending on which the form is, you need to change the file type in the open dialog.

Now that you have that open you can use the toolbar button with the tool tip text "View class code" to export your form in code. That way I'd be able to see what's really going on.

Besides that, it'll of course help to know where seom alias is created and how, if something happens outside of the form before the form is started.

If you set an alias to the recordsource and alias.fieldname to the controlsources of each column of a grid, that does not necessarly mean that's what you get at runtime. If that alias does not existing in the form's datasesseion, the grid will take whatever it get's at the moment it needs a recordsource. So you might not get what you think.

Bye, Olaf.

 

[tacs]

I can understand that if you dont specify a control source for a column then you will get the first field in the table specified in the record source for the grid. However, if you put a table name in that doesn't exist (or spell it incorrectly, my own personal favourite!!) then you get an error telling you that the alias doesn't exist. Similarly with the field, it will tell you the variable doesn't exist.

If you don't enter any data source then you'll get which ever table you are currently sitting on, with your columns filled by a matching number of fields from the start of the table.

That's correct as far as I know.

 

[Mike Lewis]

Tacs,

Your analysis is correct ... except that, if you don't have a control source, but you do have a record source, you'll get the columns from the alias specified by the record source.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

Yes, but if you assign an alias, which exists, but is not what you expect, or if some code changes the recordsource or, or, or. I could think of many things making the form not work as you think it works. You can easily fool even yourself. And if it's a form someone else started, then that's valid even more.

Perhaps the behaviour even comes from another grid of the form...I don't know the whoe form. You still even didn't explain why you were talking about the forms double click and then about the grid's doubleclick. By the way the grid's double click won't happen unless you click on a gridline or something belonging directly to the grid. otherwise you'll raher trigger the textbox doubleclick of a textbox within a grid column, unless there are several bindevent() calls that bind textbox.doublelick() to grid.doublelick().

There are many things I suppose you don't know about in foxpro and that form.

Bye, Olaf.

 

[tacs]

Olaf,
I'm not criticising your advice, far from it, I appreciate the time and information supplied by everyone that contributes to this forum.

I understand that many things can change the source of a grid. I thought I had explained that it's just a form that I can run in the IDE and as such has little, or probably no, outside factors influencing it. I didn't say that it has only 1 grid, which it does, because I didn't think it was relevant.

I did say right at the start that it was a double click on the grid that ran the code. I also incorrectly refered to double clicking the form (sorry if I mislead you there), but I thought that we were discussing a grid from the start.

I also said first thing this morning that Mikes suggestion works fine (thanks Mike) and so this is a closed issue for me.

I do understand what I am clicking on with the contents of the grid. While I have been developing for far longer than I care to remember (way back to Clipper and DOS), there are ALWAYS new things to learn and new ways of doing things. For me Tek-Tips id the ideal forum as it provides support, guidance and information that helps me and many other to do just that. Long may it continue.

 

[Olaf Doschke]

Okay, it's fine your problem is solved, tacs. But I think this thread is of low value for others, as they won't find a solution valid for a more general problem. Several things remain a mystery, eg a click on the grid will only call the grid.doubleclick method, if you don't click ona textbox within the grid.

And in regard to outside influences I again quote yourself, you said:

the RECORDSOURCE of the grid is set to a cursor that was created by a SQL command that linked several tables

This leaves us to guess where that SQL is run, eg in the form init it's run AFTER the grid has taken it's recordsource, as the form init runs after each control's init. And if it's run even before the form is called, then that surely is an outside influence.

All that can easily be determined by the viewcode you could generate from the form.

Okay, it's solved and done. It still leaves me with several open ends. I don't know yet what really was the problem and can't reproduce it.

That's somewhat disappointing. I'm not blaming this on you and finally you will need to move on in your work.

Bye, Olaf.

 

[tacs]

Olaf,
I can't say that I am surprised that you can't recreate the problem. I have never seen it before and it sounds as though no one else has come across this either.

To try to help you tie up your loose ends:

The cursor that was the record source for the grid was created in the BeforeOpenTables of the DataEnvironment.

It was a fairly standard SELECT with 2 INNER JOINS to create the cursor.

I am not sure what caused this problem to happen, and I was never sure that it was a problem with the grid. However, all I can say is that if I ran the code that is now on the click event of a 'Print' button when it was in the double click event of column1.header1.text1.dblclick of the grid it behaved exactly as I described. Copying the entire text from that double click event to the click of the button made it behave as I expected it to from the start. All of that DOES point ot it being a problem with the grid.

Whether the problem is actually caused by the grid or something else specific to this development environment, but which then affects the grid I can't say. I know that I asked a colleague to take the same form and run it and he too got the same problem. What ever it was that was causing it was doing so consistently.

I'm not sure that I can post the code as you requested as it doesn't belong to me. I am working on it for someone else and so I don't have the right to release it to anyone else without their permission.

When I say that there are no outside influences I was refering to the fact that I can take this form in the IDE and run it without having to run anything else first. The form itself creates everything that it needs or opens any tables that it needs in order to run. No parameters are passed to it, no global variables are set which it then uses.

I have used a double click event in this way many, many times and I have NEVER seen anything quite like this. I'm just grateful that with all of your help I was able to stop it from happening this time and if I ever see it again I will have a better idea of what to do.

 

[Olaf Doschke]

Thank you Tacs,

that wraps it up for me, too. I may give it a try to create some cursor in the Beforeopentables of the DE of an SCX and see what behavior I get.

Bye, Olaf.

 

[tacs]

No problem Olaf. Thanks again for your help.