Full Version: Controls on continuous forms
UtterAccess Forums > Microsoft® Access > Access Forms
paulsmithx
Greetings,
Is it possible to set a property for one instance of an item in a coninuous form?
need to set a control to visible on one line of a continous form based on a value in that row, and visible in another. At present doing this sets the state of the control in all instances. This makes for some strange behavious when the user scrolls through the form and really upsets my users.
Thanks
Paul
JayNoelOlimpo
Hi;
Can't be.
HTH.
paulsmithx
crazy.gif
mishej
Yes, that's the nature of continuous forms. There are always alternative solutions but they generally require a lot of work and so the benefit has to be weighed against the cost.
For example, you could create a number of controls (unbound) to represent a continuous form and code everything needed to populate them but you would be re-creating a lot of the code that Access provides just to gain a few features but it can be done.
ChrisO
Well as Jay and John have already mentioned, no go on visibility...directly.
ossible workaround…
Conditional formatting allows the control of fore and back color.
Depending on the exact circumstances, if the fore and back color could be set to the same as the detail back color then the control would be…invisible.
All bets are off if you wish to control the border color as well.
Little A2K demo attached, hope that gets close.
Regards,
Chris.
paulsmithx
Thanks to everyone for the replies and suggestions.
The actual problem involved setting filter values for combo boxes based on other selection that the user makes in each row. Fairly standard transaction processing kind things I would have thought.
For example consider an invoice:
select product category
select product where the list of products is limited to what is selcted in the category
Whilst I appreciate the vast number of features that Microsoft provide this is a serious limitation that I come up against time and time again with continuous forms. Coding an entirely unbound form by hand takes me back, way, way back to about 1988.
But we are here to find solutions, and so I retire to ponder.
Regards,
Paul
Schizolocal
But you can set the combo recordsource query in the OnCurrent event, and in AfterUpdate events for any controls that could affect the recordsource.
pry9991
This isn't the same problem, so forgive me for joining in with this thread, but I thought this may help someone else out there in the future.
had a simular problem. I've built a continuous form. Actually, I've built 5, all are going to sit on the same page, all viewing tables that are linked via relationships.
I want the user to be able to select a record in the first, which as you'd expect, updates all the rest based on relationships.
BUT, I wanted to allow the user to see clearly which rows are selected in each continous subform.. to get a clear 'path' across the 5 tables. This was my challenge.
So I figured why not highlight the text boxes on just the active row. I then ran into your problem, every row changed colour!!
I then tried conditional formatting for "Field Has Focus", and that worked, but only if I had the focus on that particular sub form. The moment I moved to another sub form, the row lost it's highlight... [censored].
Then I figured out this 'easy' work around:
In the form header, I created "varRowID" text box. On the "ON CURRENT" properties of the form, I have the VBA code: varRowID = Me.ID , so that each time I select a row, it populates varRowID with the ID number for the current row.
Then, in the conditional formatting, I have condition1 :
Expression Is: [varActiveRow]=[ID]
Viola. As I select a row, it becomes highlighted, and more importantly, stays highlighted as I move away from that sub form. This solved my problem perfectly!! I can select a row in one subform, it highlights, and stays highlighted as I move to the next subform, and so forth.
It doesn't solve your problem sadly, but I thought I'd share the problem/solution.
Schizolocal
In fact, you could probably set up the recordsource query to refer to user-input fields(which will be different in each record) as filter criteria. The OnCurrent event and AfterUpdate events would then only need to Requery (refresh) the combobox.
.g. "SELECT ID, ProductName, ProductRef FROM tblProduct WHERE ColourNumber = " & Forms(Me.Name)!UserSelectedColourNumber
paulsmithx
Schizolocal...there is no problem with changing the recordsource for the combo boxes based on the data contained in the row. However it changes to recordsource for all rows. The problem does no manifest unless you have a value in a combo box later in the recordset whose value is filtered out. Teh value then disappears from that instance of the combo box leaving a blank on the screen. Ther data is still in the table but thje user is confused.
niesz
How many 'variations' of recordsources do you have? Can you post some examples of your data?
Schizolocal
Then I would suggest the following:
se the Combobox for selection only (it's width only enough to show the drop-down button, no visible field, but with drop-down widths set as you need.)
Show the current value in the field in a normal (but locked) text box next to it.
Then you have the best of both worlds - dynamic combo box and values which are different in each record. (There is no compulsion for a combobox to limit to list until selected)
niesz
See if the attached helps any...
paulsmithx
So, I've managed to convince my users that there is no real problem with the form functioning the way it does. I have allayed their fears regarding data. The method I have employed is:
ombo gotfocus
check values on row and set rowsource accordingly
combo lostfocus
reset rowsource to default setting
REQUERY
The effect is that the values only temporarily disappear in other records and reappear when the user navigates to another record or another field.
Now my problem has shifted to the requery line in the lostfocus procedure. When I start the form the recordset for the combo box is loaded. If I change the filter should it not just apply a filter to the current recordset. When I remove that filter should the underlying records still not be visible? Why do I have to requery?
Thanks
Paul
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.