For the sake of simplicity, here is a test script that I would like to run during the Initialize step of an object launch point
mbo.setValue('CCIPERSONGROUP', 'TEST')
It sets the value properly, but does not save it. It saves properly when the object is saved (via the Update step of the object launch point), but not during Initialize.
Is there a way to get mbos to save on Initialize?
If you save on initialize you will be setting yourself up for "refresh" errors, "Someone else has changed the record. Refresh and try again." But it won't have been someone else. It will have been your script. So, saving during initialize is a bad idea, unless you get an independent MboSet (from MXServer, not from mbo) against a completely different record than the one that is being initialized.
Maybe you need an escalation to set that attribute on records for which the condition is true.
Related
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.
My event structure in the following part of my VI will work when I start up the program, but never again until I stop and restart. I figure I'm not doing something simple, can someone help?
The event structure is in a while loop. Again, it works once, but not after that...
You have set Enable Beeper Value change action. It will occur once you change the value of the button from the front panel, or change the value trough property node with signaling. Changing value using a local variable or property node value property will not cause Event Handler to register the event.
It seems to me your case structure is fine.
When you press "enable beeper" the event structure should execute the case you have shown and enter the case structure in the True frame.
When you press the button again, the event structure should be executed again this time processing the False frame of the case structure.
(I assume, since you have a local variable, that "enable beeper" is not latched).
If this is what you want to happen but not what's happening the issue could be somewhere else.
Is the Read from Visa function working properly? Could it be waiting for a reply from the hardware?
I am trying to create a self incrementing loop to act as a key field for my project, I have coded a counter, but every time I run the program again, it starts from 1 again, what do I do to ensure that it carries on from the last number written to file? I am a beginner to vb.net. Thank you :)
To achieve this, you can store whatever data you want to store as an application setting.
In visual studio, if you want to add a setting, go to the settings pane of the solution explorer.
Dont forget to call the save function when you are done with updating the value as the values wont get updated unless we call this function.
For more information you can refer to this URL
http://msdn.microsoft.com/en-us/library/bc6ws923.aspx
Alternatively, when the application is exited, you can save the required value to a file and when the program is opened again, you read the file and update the variable to the value stored in the file.
The Workbook.Save line in my macro is holding everything up, and while it's important that there's a save step at the end of the macro, I don't mind if it just starts saving and then hands control back to the user.
Is there such a thing as Workbook.Save BackGround or Workbook.Save vbModeLess?
Is there such a thing as Workbook.Save BackGround or Workbook.Save vbModeLess?
Definitively, no. The full list of methods available to the workbook object:
http://msdn.microsoft.com/en-us/library/office/ff847316(v=office.14).aspx
The .Save method does not have any optional arguments:
http://msdn.microsoft.com/en-us/library/office/ff197585(v=office.14).aspx
It seems you are perceiving a "problem" with your code which is not actually a problem, but normal and expected functionality, as I explained in the comments above:
When a user manually saves the file, the application is not interactive. The user can't do anything except wait for the save to finish.
The same occurs when you invoke the .Save method of the workbook object, or the Application.CommandBars.ExecuteMso "FileSave", etc.
This is necessary because (obviously) changes made while saving would not be saved, but the workbook's .Saved property would display True.
This property is used in determining whether to show the "Close this workbook with unsaved changes?" dialog when the user closes the file. If the property is True, then the user can close without any prompt. But of course if you let them make changes this will inevitably lead to unwanted data loss as the user may then close the file with saved state True and unsaved changes to the workbook which have not been reflected in the Saved property.
(Note: there are probably more technical reasons, too, but this is just the common-sense explanation)
If the length of time it takes to save the file is burdensome, you have at least a few options I can think of, first you would want to consider notifying the user that the file is going to be saved and this may take upwards of 45 seconds. This way, they do not think the program is unresponsive or otherwise hanging. You can do this with a MsgBox or a UserForm pretty easily.
Alternatively, you could use either of the above methods to prompt the user, i.e., "Do you want to save the file?"
Etc.
When excel saves a file it created a temporary file with a name like A82732KS.tmp and the quickly delete the original file and rename the temp file (possibly in an atomic operation). To do this excel has to release control of the file to avoid a sharing violation so it necessarily disables any changes in memory in order to guarantee that was is written on file and what is loaded in memory is identical.
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.