I am using "tabbed document" forms in MS Access (each main form that is open has a "tab" to allow users to easily move between forms).
Does anyone know of a way to reorder such opened forms via VBA? I have workaround code that closes all the forms and then re-opens them in the order I need, but it is clunky and slow (some of the forms are big so take a while to load, and often users have applied filters/sorts which I then need to individually re-apply, plus resetting the current record etc etc).
As all I need is to change the order of the forms on-screen, so my approach seems like overkill - but I can't seem to find info on how to do this anywhere!
(FYI I am NOT talking about the order of pages within a tab control, to avoid any confusion!)
Please attached screenshot with three tabbed forms open, I'd like to re-arrange them so eg left to right they become: #Home, Booking Detail, Enquiry Detail
Thanks
Ok, I have inadvertently figured this out.
In testing I found that if you hide a tabbed form, when you unhide it, it doesn't show up in the same position, but in fact now shows as the last form (ie the rightmost tab)
Eureka! Now to reorder the forms I simply hide them, and then unhide them in the order required. Combine this with DoCmd.Echo = False and there is, in my testing, virtually zero overhead.
Phew!
If the user is not seeing all the forms at once, you don't need to waste resource/time loading all forms at once. Load only what the user supposed to see. NavigationControl is very good for that.
Method 1
Move from tabbed documents to NavigationControl. Each tab is loaded OnDemand hence your main form start-up would be much more quicker. If the main and tabbed form are related to each other, use tabbed form's OnOpen event to dynamically change the record source.
I.e. Form_Open => me.RecordSource = Select * form T1 where T1.id = ParentForm.Id
Method 2
If you can't move to Navigation control, simulate the same effect as above.
When tab pages are changed/selected => underlying form gets a record source.
I.e.
Private Sub TabCtl2_Change()
If Me.TabCtl2.value = 1 Then
me.subform1.recordsource = source
me.subform1.LinkChildFields = linkingFieldName 'if related
me.subform1.LinkChildFields = LinkMasterFields 'if related
ElseIf Me.TabCtl2.value = 2 Then
'Your other form
end if
End Sub
This can help you to reduce your loading time.
[Cascading result sets]
In case if all of your forms are showing cascading results, you might want to consider remove record-source for all of your subforms and then re-apply at each selection.
The goal is to minimise loading time and show only necessary data the user is supposed to see/want to see. Hope this helps to have some idea.
Related
I am using unbound endless forms to display data from my database.
The data source is set to queries which provide data to show on the form.
All tinkering with the data itself on the form is blocked (entry, adding, deleting, etc.).
The data on the form can, however, be filtered through Access' standard ways (right clicking on the data and selecting the options or through the navigation buttons down the bottom of the form).
I am using another unbound form as a menu. Buttons on the form let the user open the data display forms. The buttons are connected to the forms through an on- click event that triggers a DoCmd.OpenForm ("frmOutput") line of code to display the form.
Recently I've had users report, that opening the endless data display forms from the menu, filtering data on the form and then closing the form without taking the filter out has resulted in the form not being able to be opened again from the menu (clicking the respective button results in no action whatsoever). The bug seems to even save to the application somehow and moving the (frontend) file to another machine still shows the same error of not showing the form.
It seems that the bug appears more often when people use multiple screens, and use the application on their second screen (as per their Windows settings).
Does anybody know what causes the bug or how it can be prevented?
Any pointer in the right direction is much appreciated since I am at a loss where to even start looking for the culprit!
Hard to tell but it sounds like their filter is being saved when form is closed
If you already have an event that opens the form, try to just clear the filter property after it opens. You can do this from all your command buttons by just changing the form name that gets passed to it
Private Sub OpenUnfilteredForm(strFormName as String)
Dim frm As Form
DoCmd.OpenForm (strFormName)
DoEvents
If CurrentProject.AllForms(strFormName).IsLoaded Then
Set frm = Forms(strFormName)
With frm
.Filter = ""
.FilterOn = False
End With
End If
Set frm = Nothing
End Sub
I got a form that works amazingly by itself, but the second I attach it to my navigation form. I start to get prompted for user input since this line
[Forms]![frm_addReceiveReportInformation]![cbo_PurchaseOrderID]
no longer works due to the current form becoming subform in the navigation form which was explained in
ACCESS 2010 Navigation Form Query Property
I can't seem to figure a way out of using the !form since I absolutely need to retrieve the ID from a combo box to update another combo box.
I tried multiple ways of using the !forms but I can't seem to wrap my head around how to retrieve my information that I am seeking.
I got the 2 way navigation menu(vertical + horizontal tabs). Anyone got advice or has encounter this problem in the pass, who can direct me down the right path.
To access a field inside a form, which is attached to a navigation tab, you should use the following structure:
[Forms]![YourNavigationTab]![NavigationSubform].[Form]![YourField]
Note: tested in MS Access 2013
In order for queries that contain form references to work, the form must be fully loaded. I think the problem you are experiencing is that the query in the Row Source of the Part Code combo is being evaluated before the form is loaded and therefore you are being asked to input the parameter value.
You can work around this by leaving the Row Source property of the Part Code combo empty until it gets focus for the first time, something like:
Private Sub cboPartCode_GotFocus()
If Len(cboPartCode.RowSource) = 0 Then
cboPartCode.[RowSource] = "Your Query"
cboPartCode.Requery
End If
End Sub
I sometimes just put a button on the navigation form which opens the desired form as a standalone form. It is probably not the neatest solution but it does work.
Let's start with a confession: I came from a VB6 background, and I'm accustomed to coding within the events of objects on a form, and as such my code for events ends up in somewhat random order in the code window. With this habit, it's never been very important to remember the names of controls (although I name them well)... I just double click on a button in the design view, which brings me straight to the code for that control's primary event. If I forget the name of a control, I click it and view properties. It's not a habit I've moved away from.
Well, now this is catching up to me. Using VS Express 2013, I have a form that contains a HUGE number of containers-within-containers, labels, buttons, and other doohickeys. I ported my code from VS.NET Express 2008 where this wasn't a problem. But now the act of selecting any control in the design view takes around 10 seconds before I can view its properties. If I drag to resize a control, and another 10 seconds passes before I can select another control. It makes designing this form nearly impractical.
In this particular project, I'm using use a tab control (which is never visible to the user) to design many "screens" which each contain panels full of controls. The panels for each "screen" are moved out of the tabs and docked into the main form as requested by the user changing screens. (I'm using the term "screen" to mean a window full of controls, usually maximized.)
Within the same project, a simple modal password-change form isn't slow to edit controls visually, even if the complex form is still visible in the IDE.
My question is in three parts:
First, what the heck is it spending all that time doing?
Second, is there a setting I can tweak to improve the speed?
Third, should I give up on trying to speed it up as-is, and move each "screen" into its own form for design purposes to avoid this slowness? (It's a lot of work to do that now... see next paragraph.)
Thus far I have avoided separating "screens" onto separate forms because I don't want a new window to come up when users change screens, and because code for the controls in one screen may affect the properties of controls on other screens... In such cases I prefer not to write out
form.doohickey.text = "blah"
..but rather keep it as ...
doohickey.text = "blah"
I'm using VB but I don't think this question is VB-specific.)
First off, I feel your pain. I have a management section of the application that I'm writing and I'm using a TabControl as well. I have 10 tabs so far and I've only added controls to about 4-5 tabs. I just added up the controls I have and there are about 360 controls so far on this one form and the designer file is ~3300 lines long. Currently anytime I change a property value of one of the controls or go to save the Designer, it takes about 3-4 seconds each time. I have a fairly decent machine; i5-3320M, 8GB RAM, intel 330 SSD, and it still takes a bit for it to do things within the tabControl. It also takes FOREVER to open and load the designer on that form...
What I've found is that it is easier to open a new instance of Visual Studio, create a test application, add a TabControl with the same properties, and design a new tab page from there. When I'm done I do a copy-paste into my actual project. This works great except for the few custom controls I've written in my main application project, I just have to sit and wait while adding them.
I'm now answering my own question. This is the approach I've ended up using, and it helps a lot...
My overall goal was to have an interface that didn't present a lot of windows, but still presented many different "screens".
I used to place all the different controls of different "screens" on separate panels, which were each contained in separate tabs of an invisible TabControl. I would then move those panels to my main form as needed by changing their Parent property of each panel as needed. The only problem with this is that the Winforms designer got ridiculously slow as the number of controls on a form increased into the hundreds.
Now, I am now designing each "screen" as a separate form, each of which contains a panel whose Dock property = Fill. Such a panel contains everything else on the form. The form itself never becomes visible.
As needed for to view various screens, I execute:
ScreenForm.Panel1.Parent = Mainform
...or, depending on how I lay it out...
ScreenForm.Panel1.Parent = Mainform.PanelXYZ
...I also either unload or hide any panels which already exist in the panel's new container.
I was GLADLY SURPRISED to find that the code for the various events of the controls contained in the panels would still run, because such code exists in the first form's file, not the displayed form's file. Luckily, it seems I was wrong. Event code follows the control itself. I can copy/paste not only controls, but also their corresponding event code to new forms for easier development and a faster Winforms designer.
All of this is similar to a MDI interface with maximized windows, but no title bar or [X] is displayed.
Essentially I'm doing everything as I did before, except using separate forms with panels instead of separate tabs with panels. The WinForms designer is much quicker because there aren't so many controls on any form.
I think I accidently found a workaround for saving a lot of time when changing the name of a control on a overpopulated container/project. Before you change the name, toggle False/True the "Generate Member" property of the control you want to rename(I believe you can also locate this under the "Name" property). This adds a few more clicks to the procedure but saves a lot of time. My not-yet-finished project has over 4000 controls and multiple forms and some of them are very "heavy" (10 - 20 seconds to normally change the name of a control). This, of course, don't help in anyway with the loading time of the project (about 35 seconds for me) but I can live with it. Let me know if this works for you too.
I am writing a Windows Forms application in VB.NET. I have three forms: the main form, which shows a list of accounts, the account form which allows the user to view/edit the information for a specific account, and the policy form which allows the user to view/edit the information on a specific policy for that account. I want the forms to appear as if they are all the same window. Example: when the application starts, the user clicks an account name in the list box on the main form and clicks "edit". What I want to happen is that the window stays in the exact same place and stays the same exact size, only the content of the main form appears to be replaced with the content of the account form. Same thing if the user then chooses to edit a policy from the account form. When the user finishes and clicks "save", the main form comes back up. Through this entire use case, it would appear to the user as if they were viewing the same window the entire time, with the content of that window changing.
How can I do this? I have tried something like:
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.Show()
Me.Close()
The problem is that if the user moves the original window, the new window appears where the parent form originally appeared, not where it ended up.
I see this is already in the comments, but what I have done in this case in the past is build each "form" in the application as a custom control. Then I have one actual form, and navigation works by changing which custom control is currently loaded on the parent form. To move from one screen/view to another, you remove the current custom control from the form's controls collection and add the new custom control.
I believe this is superior to manually setting the startup position and size, because you can use the form's .SuspendLayout()/.ResumeLayout() methods to hide the interim state, where there is no control loaded, from the user. This is harder to do when you want one form to be completely replaced by another.
This also makes it easy to set certain form properties in one place and have them be consistent for the application. You can even have an area on the form with controls that will now show in every view.
When using this pattern, I typically have each of my custom controls inherit from a common base. You may not have anything specific you will do with that base at the outset, but it almost always comes in handy later.
Finally, switching to use this scheme is easier than you think. Just go to the code for the each of your current forms, and you will find that each class currently inherits from System.Windows.Forms.Form. Most of the time, all you really need to do is change them to inherit from System.Windows.Forms.Panel and you're most of the way there.
As others have said, it may be better to redesign your application using custom controls or panels etc.
However, to answer your question regarding the seemingly random location of your forms, the first thing to check is that each form has it's StartPosition property set to Manual.
If your main form is resizable, then I would also add code to adjust newForm to the same size too.
I hope that helps with your immediate issues; so that you can move on to redesigning the application!
good morning there is another way . set property for second form to (top most) and use also
from2.show();
that make you switch between forms and keep form2 top other
Thanks
try using ShowDialog()
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.ShowDialog()
Me.Close() <-- removed this
I am working on a Word VBA macro app for 80 or so users. The office has high staff turnover, so training suffers, and so one of the self imposed requirements for this project is comprehensive, friendly documentation. However, to supplement this, and to save newbies having to open up a 100 page document when they want to try something new, I want a status bar on every userform (there are five) that provides contextual help. I find tooltips annoying.
I don't have a lot of experience, so I was wanting to
Essentially, I have a file containing every status string. (This is currently a text file, but I was wondering if I should use a spreadsheet or csv for ease of editing by other staff in future.) Every control has a MouseMove event which refers to a function: getStatus(cID) that opens the file, grabs the line and displays it in the status label. It also grabs a few parameters from the same line in the file, such as whether the label is clickable (to link to a page in the help file), and what colour the label should be.
So a few questions really:
Will the application be slow if a userform is constantly referring to a file? It feels fine to me, but I've been in it far too long, and I'm the only user accessing that file. There will be 80 constantly accessing it.
Is MouseMove over a control the best way? Should I instead use co-ordinates?
Most importantly (in terms of me having to do as little work as possible) is there some way to do this so that I do not have to have a MouseMove event on every single control? I have a good few hundred or so controls, each with their own identifier (well, not yet, but they will if this is the only way to do it). Maybe when the form loads I could load ALL the possible status lines so they're ready for whenever the control is moused over. But then, maybe the loading time is negligible?
Appreciate any ideas or thoughts - especially if VBA already has a whole range of functions to do this already and I'm just trying to reinvent the wheel. I can't use the application status bar, because the user rarely sees the application itself.
Thanks!
EDIT:
It is for both data entry, clicking around and a bit of document generation.
It is a controlled environment so macro security issues aren't a big concern for me - and if something goes wrong it's someone else's fault or problem :)
Is this data entry app or do they just click stuff? Because often the field with focus is different to the item the mouse is hovering over, this can cause a lot of confusion.
Constantly reading from a file is a huge waste of time and resources - it is much better to load them only once into an array or collection when the form is loaded.
On MouseMouse event is better than coordinates because you can move things around without worrying. It's a lot of code but you should be able to generate most of that if you have a list of control names because the code should be identical.
ie
Sub Control_MouseMove()
DisplayStatus(Control)
End sub
I would consider the StatusText property and ControlTipText property of controls for this kind of help.
StatusText
This example sets the status bar help text for the form field named "Age."
With ActiveDocument.FormFields("Age")
.OwnStatus = True
.StatusText = "Type your current age."
End With
ControlTipText
This can be assigned from the property sheet for the control.
Private Sub UserForm_Initialize()
MultiPage1.Page1.ControlTipText = "Here in page 1"
MultiPage1.Page2.ControlTipText = "Now in page 2"
CommandButton1.ControlTipText = "And now here's"
CommandButton2.ControlTipText = "a tip from"
CommandButton3.ControlTipText = "your controls!"
End Sub