Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Duplicated Controls & Off-Form, Why 3

Status
Not open for further replies.

stanlyn

Programmer
Sep 3, 2003
945
US
Hi,
In a page of a pageframe, something has created controls based on the grid there, and then duplicates them and adds a "2" their names. The page should only have a grid control. The grid control is there along with two sets of controls outside the grid. They are also positioned off-screen like top = -2055 and left = -500.

Are these controls needed? I discovered them after changing some controlsource names, then edited the grid to match them. Program errors about controls containing the old name. The controls are also NOT shown in the "Document View" window.

41_hfa0va.jpg


1. Any idea what would cause this?

2. Any idea on how to multi-select or deselect them as a group and delete them, instead of scrolling the property sheet, selecting a single control, then select the form and pressing delete... then repeat... I know I can make the page the active control, then "Ctrl A" to select them all, then delete. Any way to select and delete them from a selectable list?

Thanks,
Stanley
 
Stanley,

As the form file is a table in vfp, may be you can open the form as
Code:
USE <yourformname>.SCX
(close the form before issuing above command. Otherwise, you get an error. You know that!)

Then, issue command
Code:
BROWSE FOR UPPER('Left = -') $ UPPER(properties) OR UPPER('Top = -') $ UPPER(properties)
Then, delete all those records. But, please check those which are shown not the ones you would need it later.

Note: The UPPER function in above command may not be necessary. But I am not sure in vfp properties field the content may saved in upper cases in any situations, say, according to your vfp configuration on fonts used


Rajesh
 
Hi Rajesh,

I just finished updating my questions. The top and left values are all over the place, maybe negative or positive, unpredictable.

Yes, I have hacked the scx many times before and find it tedious and easy to delete the wrong things as I would have to check each row before deleting. I was hopeful of the document window, but these controls are not shown.

Thanks,
Stanley
 
Stanley,

What do you mean when you say "I was hopeful of the document window, but these controls are not shown."?

The 'Document View' window I know is used to view the code not the properties of the object, isn't it?
I don't think, you will get property list in that window if the object doesn't have any code associated with it. (Other experts can correct me please).

Or, do you mean the Properties window (object properties)? The image you added is of Properties window.

And for the reason, may be by mistake when you pressed Ctrl+V sometime in between your editing course, those object were in a 'selected' state.
Then vfp copied them on to the form. I am not able to think of any other cause.

Rajesh
 
Hi Rajesh,

With the properties window, I have to do them one control at a time and not good as it takes too long. I'm a bit nervous about doing a select all and deleting off-screen (hidden) objects.

I don't use the 'documents window' and was hopeful that it could do the job. It won't. So, is there any other way to select them from a list other than hacking the scx?

I'm glad to hear that vfp did not create the controls as some sort of dependencies. I must have copied them in and I hope I accidently did.

Thanks,
 
Stanley,

Why don't you just make a copy of the form to experiment with. In the copy, select in turn each of the relevant controls from the drop-down list at the top of the property window. Then click on the form designer's title bar )not on the form itself, as that will select another control), then hit the Delete key.

Once you've done that, run the form and see what happens. If all is well, keep the copy and remove the original (or keep it as a backup).

You don't have to mess with the SCX file to do this.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Stanlyn,

I can't help ou with the "why" question. It's nothing that happens automatically or by a bug. Someone must have created and put them there.
You can get at the records having a 2 in the object name of an scx with.

The Docuent View is a helper window to allow you navigate to proceddure and function definitions in a code window, not about objects of forms. So documents are not forms but PRGs are referred to as documents.

help on document view said:
Makes it possible for you to view and navigate to any procedure, function, or #DEFINE definition, class or preprocessor directive [highlight #FCE94F]in your program[/highlight].

[bbox][/bbox]

You already did it again, you rejected a solution. You can easily find all such controls that are having off screen top/left, have a name ending in 2 and are part of a page of a pageframe.

Code:
USE your.scx
BROWSE FOR Right(objname,1)=='2' AND parent='Form1.Pageframe1.Page2' and ('Top = -' $ properties or 'Left = -' $ properties)
And you can make the for condition more selective than that, by also checking their baseclass to be textbox, for example, or grid.

Besides this possibility, you already got another solution yourself, you use CTRL+Click to activate that specific page and get all controls inclding those off the visible page canvas with CTRL+A, then just deselect all visible controls you want to keep by holding down a shift key and clicking on the controls to keep to deselect them. The remaining selection are the off screen controls. In this case the properties window will show a "Multiple Selection" entry, but not the list of controls. You only get a list of records with the browse methed.

You are mainly struggling with your rejection of solutions. You can't be helped, often. You refuse to be helped the way you argue with utter excuses why a solution isn't viable to your case, too risky or whatever.

HAving the browse you can verify more things once you have the list. You can't see all memos at once, yes, but you can double click on them to open a satellite window and scroll through records or you could actually add editboxes into the browse window and see the memo contents in the browse.

Chriss
 
Mike,

Mike said:
Why don't you just make a copy of the form to experiment with. In the copy, select in turn each of the relevant controls from the drop-down list at the top of the property window. Then click on the form designer's title bar )not on the form itself, as that will select another control), then hit the Delete key.

Once you've done that, run the form and see what happens.

You don't have to mess with the SCX file to do this.

What I did was copied the form to a safe place, then selected the page in the pageframe, then did a Ctrl+A and deselected the visible controls, and pressed delete. They are now gone. I ran the form and, no errors...

I really didn't want to hack the .scx, although I have a lot of experience doing it, and still do it today with reports.

I asked this here as this has happened once before and I was worried that maybe vfp was creating some dependencies and I sure hoped it didn't. It was new to me.

Thanks,
Stanley


 
Chris,

I was mainly asking 2 questions of which you answered "cannot help with the why" question.

The other question was about a way to select and/or deselect the off-form controls in a list, of which is clear now that no such way exists. I also stated that I know how to hack the .scx and also came up with the Ctrl+A routine that I used. Sometime recommended solutions are not the best solutions as many times all the details are not presented up-front.

When I asked the question only a few hours ago, I physically and mentally was not up to the task of hammering out the hacking code that you provided as I've been at this and other recovery tasks for 18+ hours now. My main concern was with the 1st question (the why), and that has been answered. Actually, both questions have been answered.

And thank you for your efforts in offering solutions, and please don't get upset if I don't use it. I do use a lot of your suggestions, but not all.

Thanks again,
Stanley

 
It's okay, stanlyn.

I'm not saying I won't help you anymore. Just a note about the solution you now picked as suitable.
You selected all controls of a page now, then deselected the visible controls. The only thing you knew for sure about the remaining selection is, that they are controls of that page.
You can't take a look at the individual controls of that selection, the property window only will how you common properties with a common value about this "Multiple Selection".

In a browse FOR you instead can look into every aspect of these controls, all relevant properties are even in the properties memo.

So look at what you did: Your "risk assessment" is wrong. you found it less risky to delete this unseen selection and too risky to look into the exact records you would have got from the browse, which also Rajesh suggested to use.

Chriss
 
Another option would be to select each of the controls in turn in the drop-down list at the top of the properties window, but instead of deleting the controls, you just change their Top and Left properties to more reasonable values. Or, better still, choose "Reset to default". That way, the controls will become visible and you will be able to see exactly what they are, how their properties have been set, and what code if any exists in their methods.

Going further, you could then search the entire code of the form for any mentions of the names of the controls. If found, that will give you a good indication of what they are used for. If not found, it is more likely that it will be safe to delete them.

My main point is that it is unnecessary to open the SCX. For me, hacking a SCX, VCX or FRX will always be a last resort.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Hi friends,

How do we check which answer has been chosen as suitable or which answers were given stars?
I have never tried to check these but now just our of curiosity after seeing Chriss's text.

Rajesh
 
As said earlier, I was in my 15-16 hour of work when I discover this issue. I was not going to spend the next couple hours undoing what I thought that just maybe vfp had created them for who knows why. I know that I did not intentionally create them, and I created the entire form recently from scratch.

Chris, Why would you say that my risk management was wrong, when I (before Mike mentioned it) created a copy of the form, then did the select all, unselect the visible controls and deleted the rest. You keep forgetting that I created this recently from scratch, so I should know what should be and not be there, AND I made sure I had a way back, which translates to "No Risk" to me.

Once again, I started this thread asking if it was possible for vfp to auto create controls for some dependency/other reason, as I have only encountered this only once before in all my years of developing.

If for some reason, the deletion of all those hidden controls caused an issue, my steps would be to:
1. revert back to the saved form,
2. start examining each via the properties window,
3. delete once determined they need deleted,
4. and test...

When Rajesh said in his 2nd post that he had never heard of vfp duplicating controls and confirmed by others later, which I had never heard of either, I concluded that his assumption on what might have happened was probably correct.

I started out doing what Mike suggested by selecting each in the properties window and changed their top and left properties to on-screen and deleted them. I did 10-20 and realized there were the same group that was duplicated first (without the "2" suffix) that also needs deleted. There are just too many to do and thought "there must be a quicker way".

This would be a good time to ask the experts if there is a better vfp way to select them from a list and delete them, as in multi-select. This would have to be in a list as those controls were all off-screen. Turns out there is no such tool.

Since I know what should be there or not, the quickest way was to select page, then select all controls on page, deselect on-screen controls, then delete, and test. Done... and saved several hours. At this point I've been at this for 15-16 hours already today and was trying to plow thru it.

Before going to bed, I thought I would ask the 2 questions and would have answers tomorrow. Well, Rajesh quickly answered and before quitting for the day/night I would at least try the mass blind deletion, and it worked. It wasn't really blind as I knew that I had not intentionally put them there.

I also use controls whose visibility is .f., but I never place them off-screen whereas the out-of-site-out-of-mind mentality kicks in.

Mike said:
search the entire code of the form for any mentions of the names of the controls. If found, that will give you a good indication of what they are used for. If not found, it is more likely that it will be safe to delete them.

I did that in the very early stages after I changed the controlsourse names of the known controls within the grid. When running the form, it was throwing errors with the previous names mentioned. I looked for them using "Code References" and found none. More digging revealed the PageFrame1.pagLineItems had 6 visible controls and some 50-60 controls doubled twice, the 1st set was regularly named and the 2nd set had a 2 suffix. Far too many to scroll the property sheet, click it, then select form, then click delete. There were labels, textboxes, and editboxes.

And Chris, you better not stop helping me, as you have taught me a lot and I continue to learn. And please don't be offended if I don't do it your way, which at times are way over my head causing glazed eyes.

I've said it before, I normally don't live in VFP, but have been in the last 2-3 weeks as I have some deadlines quickly approaching, plus all the other non-vfp tasks I've been blessed with.

Thanks,
Stanley
 
Mike said:
For me, hacking a SCX, VCX or FRX will always be a last resort.

Yes, and me too, and only when I'm firing on all 8 cylinders. I start losing a cylinder per hour past about 12 hours of up time.

What I would give to be 30, or 40, or 50 again when I could easily juggle 4-5 layers in my (not computer) memory.

I started out programming at age 27 using filepro16+ on a SCO Unix multi-user system where we had to use numbers as fields and 2-character variables as variables. Vars like aa-az, ba-bz and so on. Coding was done on an IF:ELSE template with labels. Handling 4-5 layers of these was easy then, and not anymore. Who said that time has something to do with this?

Thanks,
Stanley
 
Stanley,

you said:
stanlyn said:
easy to delete the wrong things as I would have to check each row before deleting
Well, the FOR condition allows you to know everything you want to know about these controls, the property window "Multiple Selection" item will only show common values of common properties and won't allow you to know what you delete.

I noticed that you made a copy before doing all this and have a way back. That's fine but also something I assume one does in such a situation. I also noticed you say that not all controls' name to be deleted ended in 2, fine. You have full control over the for conditions you set for finding all the off-screen controls.

So while you think of hacking the SCX as the higher danger, I conclude that's actually the other way around here. You have no control other than the testrun of the form working, and that can also be deceiving until you get to a point where something is addressed. A test is never proof of something.



Chriss
 
Stanley, you seem to be thinking along the right lines.

To answer your original question, I can't think of any circumstances where VFP would take it into its head to automatically create controls without the developer's knowledge or agreement. The only possibility that comes to mind is if you copy and paste a control and inadvertently hit CTRL+V twice. That would create an extra copy of the control, almost superimposed on the first (which means that you probably wouldn't notice it). But that wouldn't explain why, in this case, the relevant controls were outside the visible form.
What I would give to be 30, or 40, or 50 again when I could easily juggle 4-5 layers in my (not computer) memory.

Ha! You're touching a nerve there. <g>

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Stanley,

Mike said:
if you copy and paste a control and inadvertently hit CTRL+V twice

When I see this, a weird thought!
Please check your keyboard for any keys having 'habit' of getting stuck and firing multiple times in between your typing :))

Rajesh
 
A paste operation by keyboard doesn't explain off-screen controls, contrls then are pasted just a few pixles to the right and down from their original position. But if you right-click and use paste from the mouse context menu, you paste at the mouse position.

It still doesn't explain it, though. Even if you move the mouse pointer off the form the topmost and leftmost control is pasted partly visible in the bottom left corner of the form or of the page, if a page is activated. Also, the off-screen positions of the pasted controls then is with too high top/left positions, not with negative values.

The nagative top/left values point out that at some point controls were made invisible by moving them off-screen that way intentiaonally, using the properties window. You could only find out more about that if you look into the positions more closely in the backup copy of the form. It's still very certain there isn't a VFP automatism to duplicate anything off-screen.


Chriss
 
A pasted control for me is always pasted on-screen 8 pixels down and 8 pixels to the right of the original and always on-screen. Cannot explain wt the 3-4 digit negative numbers.

Good to know that VFP isn't doing it.

Stanley
 
I raised the point about CTRL+V only as something that might conceivably happen, not something that was likely, and I made it clear that it wouldn't explain the fact that the controls were off the screen. So let's not spend any more time on that particular point.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top