I've got a FontDialog box called aFontDialog.
Can I detect changes made to this dialog box?
Initially my object creates the dialog using this code aFontDialog.ShowDialog, the user than makes changes, then if the user is happy with their changes then the application will receive Windows.Forms.DialogResult.OK:
Is it possible to detect any changes made to this dialog by the user? Will I need to record the state of the different aspects of the dialog before and then compare to how they are after - or are there some properties or methods built into this dialog box that help me find any changes?
The most important concern here is - why do you need to know the changes. See, font is usually not a transactional object, so you normally don't need to avoid excessive network traffic or minimize number of database roundtrips.
I would just look if user pressed OK. If yes, set the new font, regardless of how similar it is to your current one. It's just one line of code - simple as assigning this new font to the old one:
Me.Font = MyFontDialog.Font 'Me could be any control in this case
Besides, I think it is your only way, if the font is different. Meaning you cannot for example set Font.Bold = True, because it's read-only. And it would not take a lot of processing time either, so no point in optimizing it.
If you really want to, you can examine FontDialog.Font after checking DialogResult for OK, and compare to what you passed there, although I don't see where this would be useful.
Related
I have a database where I don't want some fields showing depending on data in other fields. I'm still new to VBA, having learnt how to do things I need via the internet (there's not much call for it in my job so like to try it out on side projects) for the things I need and have managed to create some code that hides certain fields that aren't needed, depending on what's been entered in another field and that works okay, if not perfectly (I'd like it to only work on the current record and not all of them at once but will worry about that later). My problem is, if I'm entering information onto a record and any of those fields become invisible exactly as I would want them to, then if I have more records to complete and load a new record, those hidden fields are also hidden on the blank record before any data has been entered and I want each new record to show all fields from the outset.
Another thing I've noticed is that if I close the database, next time I go into it the hidden fields have unhidden themselves again so I know I'm missing something important.
Here's a screenshot of a bit of the code where I want 2 other fields (What_reason and Date_sent_to_new_owning_School) to be visible depending on whether the answer in the current field after update is "Standard" or "Non-standard":
I'm sorry if this is really entry-level stuff but I AM entry level and trying to learn. This bit does work, albeit not perfectly as I'd like it to only work on the record I'm in at the time, and not go through and hide that field in all the other records at once (which it's doing).
I've searched everywhere but can't find the answer and although I've tried, I'm nowhere near good enough at VBA to try and use common sense to work it out. Is this something that can be done? I'm okay with computers generally and with Access too but I'm aware there's an awful lot I don't know and this is why I'm trying to do new things and learn stuff that I've not used before. I have tried all day to get this to work but am admitting defeat and am hoping somebody here will be able to help me. I'll probably need 'idiot level' advice if that's possible, I know my limitations. :)
Do you know how to use the Event tab in the Property Sheet? You can set all of your fields to [field].Visible = True on either: On Current, On Load, or On Open
Screenshot of the Property Sheet and for the field that determines the visibility of all of the other fields; you can use the Event: After Update so that way when you click/tab away from that field, it'll make those changes for you!
Property setting affects ALL instances of control. Control will be visible/not visible for all records depending on conditions of current record. Therefore, dynamically hiding controls on form set in Continuous or Datasheet will NOT give the desired result of
only work on the current record and not all of them at once
Db is not going to 'remember' dynamic setting - code needs to be executed when form opens and/or navigating records - so it is needed in OnCurrent event as well as control's AfterUpdate.
Conditional Formatting can dynamically enable/disable textbox/combobox by record although control is still visible.
I have a form for viewing data in a table, which can open a pop up form to edit the data.
When data is edited in the pop up form, Access throws a write conflict error upon closing that form and returning to the original.
The strange behavior I'm experiencing is that when I make a change to the popup's class module in VBA, even if I immediately undo the change and save, the error will be resolved exactly once.
To be clear:
I make a change to the popup's class module in VBA (even a change I immediately undo and re-save)
I can open the pop up from my original form, edit records, then close the pop up. No error is thrown on closing the pop up.
I then open the pop up and edit records a second time. Then upon closing the pop up a write conflict error is displayed. This continues each subsequent time.
I now make a change to the popup's class module (again, even a trivial one), the error is resolved for one edit again, and the process repeats.
Does anybody know why this behavior could be occurring? Any help would be much appreciated.
Well the issue centers on if two users, or in this case two bits of code try to edit a record that is already dirty.
If the main form causes the record to become dirty (changed, but not saved), if then you run ANY other code that ALSO changes that data, then you get the conflict.
The simple solution then is to ALWAYS ensure that the the current forms record is safely tucked away and saved before you run + call code that might change that dirty record. And that includes that popup form + class.
So in your code that launches the form/class code? Do this RIGHT BEFORE you launch that 2nd form:
If me.Dirty = True then me.dirty = False
So, the above will safe write out the dirty record, and now you are free to launch/run any other code that might change that record. And because you run the above? Well, the record is not dirty anymore, and thus you should not see nor receive a write conflict error.
So adding a check to save if dirty before you launch/run that additional code/form will resolve this issue. In fact, as a habit, for just about "any" launching of additional UI forms, it a good idea to safe tuck away and save the current forms record when launching additional UI bits and parts.
I'm using a video capturing control called VideoCapX and I've hit a bug, and after hours of debugging, I've determined that the only way to fix the glitch is to restart the program aka. reset the control.
I'm wondering is there any way to programmatically recreate a GUI control aka reset it to the way it was when the form opened.
I know this is a cheap fix, but at this point it's my only option.
In general, this would work:
Me.SomeControl1.Dispose()
Me.SomeControl1 = New SomeControl
'Configure SomeControl1 here.
Me.Controls.Add(Me.SomeControl1)
where SomeControl1 is the field created automatically when you add the control to the form at design-time. The first line removes the existing control from the form, the second line replaces the existing control with a new one of the same type and the last line adds the new control to the form. You need to set the appropriate properties of the new control in between, so you might want to keep the old one around to get the required property values from, e.g.
Dim newControl As New SomeControl
'Configure newControl here, e.g.
newControl.Location = Me.SomeControl.Location
Me.SomeControl1.Dispose()
Me.SomeControl1 = newControl
Me.Controls.Add(Me.SomeControl1)
Note that assigning the new control to the existing field will automatically connect any event handlers with a Handles clause.
That said, the fact that you're using what is likely to be a fairly complex custom control, it's hard to say whether there might be some other required steps 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