I’m using BPM 6.4 with all the defaults when installing. I created a business process which has a signal event in "Catching Intermediate Events", and I am trying to change the property ‘Cancel Activity’ from true -> false. The default is true. I change it to false, then I save my business process, reload the page and the property ‘Cancel Activity’ has changed back to true. Is this a bug?
The cancel activity property only is used in specific use cases, for example when it is used as a boundary event (to indicate if the node it is attached to should be canceled or not when the event happens). In situations where the property is not used, the value will not be persisted. We are looking at improving this in our new version by making sure the property is hidden / not editable in cases where it is not useful.
Related
I cant figure out how to reset changes made to one context of a sap.ui.model.odata.v4.ODataListBinding.
If I edit a context via setProperty and call hasPendingChanges() afterwards, it returns false (I guess because the ListBinding itself havent changed). But then, how am I supposed to reset the changes I made to this specific context without resetting all the changes for that ListBinding? I think I need a ContextBinding instead of a ListBinding, but I dont know hwo to get it without rebinding the context to a single entity.
Thanks for any kind of help!
https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v4.ODataListBinding%23methods/hasPendingChanges
Returns true if this binding or its dependent bindings have pending property changes or created entities which have not been sent successfully to the server
So maybe the change was already sent to the server. Check your ODataModel if you are in $auto mode and a request is send the moment you called setProperty
I have linked many parameters in my model to values in the internal ModelDatabase. This works great.
Now I want to allow the user to import a new "Input File" for a specific scenario. I have added a fileChooser element on the Simulation Experiment screen and in the onUpload action I use the ModelDatabase.importFromExternalDB to upload the relevant sheet to the relevant table.
However, this does not seem to work. Initially I thought that the update simply did not happen but when I stop the model in the AnyLogic IDE and start it again in the IDE, the new values are used.
It appears as if the update only happens on startup/close and that the database is "static" while running. I did set the auto-commit parameter to true on the importFromExternalDB function, but this made no difference.
Is there a function I can call to force a "refresh" of the internal database?
You probably load the data at runtime using the default code such as selectFrom("some String with query")
However, these always load from the cached dbase to speed things up.
Instead, you must force AnyLogic to load from the live dbase using an additional argument. In this example, it would be selectFrom(false, "some String query")
This is also documented in the help:
So go through all queries in your model and add the appropriate boolean arg to force-load from the non-cached dbase.
I have a working JavaFX application. It has three main parts:
A list of signals visible globally to the entire application. Each signal has a String value property that is observable. This list is instantiated before the JavaFX scene is constructed, the signal list constructor is run in the Application FX thread.
A JavaFX table implemented as an Observable Array List so that as signal values change they are automatically updated on the GUI.
A simulation engine that runs a loop that changes signal values. This loop is run in a worker thread.
I am fully aware that GUI elements like selection lists, text in boxes, etc. can only be updated in the Application FX thread. I use Platform.runLater(someRunnableThing) to do that. However, what blindsided me was that even changing a signal value, which changes the value of the observable String property, must be done in the FX thread or not-in-Application-FX-thread exceptions will be thrown.
Curiously the application still works fine despite these exceptions, because eventually (instantaneously to a human observer) the changed value is picked up and displayed. I only noticed this when doing final checks of run-time behavior before release.
It is a very common thing for a worker thread to be changing variables in the background while a GUI is displaying information based on the changing variables. Platform.runLater() is expensive and somewhat non-deterministic. Since the worker thread is not touching the GUI and the application FX thread can choose to grab updates whenever it wants it seems draconian to me for Java to force this behavior.
Have I missed something about modifying observed properties? Any thoughts and ideas appreciated.
There are no rules about updating JavaFX properties from background threads. The only rule is that you cannot update nodes that are part of a scene graph from a background thread, and there are no plans (and likely never will be) to relax that rule.
You didn't post any code, so we can only make educated guesses as to what the actual problem is. What is likely happening is that you have a listener or a binding on one of the properties (or observable collections) that is being changed from your background thread, where the listener/binding is updating the UI. Listeners with observables (including listeners created and registered by bindings) are, of course, invoked on the same thread on which the observable is changed.
So if you have something like
someApplicationProperty.addListener((obs, oldValue, newValue) -> {
someUIElement.setSomeValue(...);
});
or perhaps
someUIElement.someProperty().bind(someApplicationProperty);
just replace it with
someApplicationProperty.addListener((obs, oldValue, newValue) -> {
Platform.runLater(() -> someUIElement.setSomeValue(...));
});
In other words, you can continue to update your application properties from the background thread, as long as your listener updates the UI from the FX Application Thread.
In the case where the listener is registered by the UI component itself, you must ensure that the observable with which the listener is registered is changed on the UI thread. This is the case in the example you allude to, for example updating the backing list for a ListView or TableView. You can do this either by directly invoking Platform.runLater(), or by placing a layer in between the model and the UI. For the latter approach, see Correct Way to update Observable List from background thread
Also maybe see http://www.oracle.com/technetwork/articles/java/javafxinteg-2062777.html
I'm trying to use RevertAllInCurrentGroup to undo the last operation but it doesn't seem to work. Actually what I really want to do is just remove the undo from the history; I don't care whether the undo is applied or not.
In some init code I have:
// 'component' is a MonoBehaviour-derived class. Here I create the default editor for the component
m_editor = Editor.CreateEditor(component);
And then in OnGUI in my EditorWindow:
m_editor.OnInspectorGUI();
// ..'hasChanged' is set to true if the user changed some property
if (hasChanged)
{
// ..do some stuff using the new values on the object, which includes sending a message to a server
Undo.RevertAllInCurrentGroup();
}
When I call RevertAllInCurrentGroup I get InvalidOperationException: Operation is not valid due to the current state of the object in some Stack object in GUILayoutUtility.EndLayoutGroup. I figured maybe I shouldn't be doing the revert in OnGUI, so I changed it to set a flag and do the revert in Update but that doesn't make any difference (except I obviously no longer get the exception).
Does anyone know how to use this function, or if there is some other way that I could undo the last operation that was applied by the Editor instance? I've tried using Undo.RegisterCompleteObjectUndo and Undo.ClearUndo but they don't seem to do anything either (the undo operation still appears in the undo stack).
For clarification, I'm dynamically creating GameObjects with components in the editor based on messages I receive from a server (which is a running Unity game, which could be inside or outside the editor - this is a live update system). Then I allow editing of those components, and send the changed components back to the server. I'm rendering my own inspector UI and I wanted to use the built-in Editor instances for components (e.g. so the built-in CameraEditor will be used if there is a Camera component).
The only problem is that using the built-in editors causes undo operations to be added to the stack, but I really don't care about these undo operations because the GameObject they apply to is just a temporary placeholder GameObject which is continually updated every coulpe of seconds, whenever I receive a new message from the server.
if what you want is the same as clicking on the Edit->Undo menu (or as you put, undo the last operation that was applied by the editor), use below code:
Undo.PerformUndo();
I run into this regularly, and am just looking for best practice/approach. I have a database / datamodule-containing app, and want to fire up the database/datasets on startup w/o having "active at runtime" set to true at design time (database location varies). Also run a web "check for updates" routine when the app starts up.
Given TForm event sequences, and results from various trial and error, I'm currently using this approach:
I use a "Globals" record set up in the main form to store all global vars, have one element of that called Globals.AppInitialized (boolean), and set it to False in the Initialization section of the main form.
At the main form's OnShow event (all forms are created by then), I test Globals.AppInitialized; if it's false, I run my "Initialization" stuff, and then finish by setting Globals.AppInitialized := True.
This seems to work pretty well, but is it the best approach? Looking for insight from others' experience, ideas and opinions. TIA..
I generally always turn off auto creation of all forms EXCEPT for the main form and possibly the primary datamodule.
One trick that I learned you can do, is add your datamodule to your project, allow it to auto-create and create BEFORE your main form. Then, when your main form is created, the onCreate for the datamodule will have already been run.
If your application has some code to say, set the focus of a control (something you can't do on creation, since its "not visible yet") then create a user message and post it to the form in your oncreate. The message SHOULD (no guarantee) be processed as soon as the forms message loop is processed. For example:
const
wm_AppStarted = wm_User + 101;
type
Form1 = class(tForm)
:
procedure wmAppStarted(var Msg:tMessage); message wm_AppStarted;
end;
// in your oncreate event add the following, which should result in your wmAppStarted event firing.
PostMessage(handle,wm_AppStarted,0,0);
I can't think of a single time that this message was never processed, but the nature of the call is that it is added to the message queue, and if the queue is full then it is "dropped". Just be aware that edge case exists.
You may want to directly interfere with the project source (.dpr file) after the form creation calls and before the Application.Run. (Or even earlier in case.)
This is how I usually handle such initialization stuff:
...
Application.CreateForm(TMainForm, MainForm);
...
MainForm.ApplicationLoaded; // loads options, etc..
Application.Run;
...
I don't know if this is helpful, but some of my applications don't have any form auto created, i.e. they have no mainform in the IDE.
The first form created with the Application object as its owner will automatically become the mainform. Thus I only autocreate one datamodule as a loader and let this one decide which datamodules to create when and which forms to create in what order. This datamodule has a StartUp and ShutDown method, which are called as "brackets" around Application.Run in the dpr. The ShutDown method gives a little more control over the shutdown process.
This can be useful when you have designed different "mainforms" for different use cases of your application or you can use some configuration files to select different mainforms.
There actually isn't such a concept as a "global variable" in Delphi. All variables are scoped to the unit they are in and other units that use that unit.
Just make the AppInitialized and Initialization stuff as part of your data module. Basically have one class (or datamodule) to rule all your non-UI stuff (kind of like the One-Ring, except not all evil and such.)
Alternatively you can:
Call it from your splash screen.
Do it during log in
Run the "check for update" in a background thread - don't force them to update right now. Do it kind of like Firefox does.
I'm not sure I understand why you need the global variables? Nowadays I write ALL my Delphi apps without a single global variable. Even when I did use them, I never had more than a couple per application.
So maybe you need to first think why you actually need them.
I use a primary Data Module to check if the DB connection is OK and if it doesn't, show a custom component form to setup the db connection and then loads the main form:
Application.CreateForm(TDmMain, DmMain);
if DmMain.isDBConnected then
begin
Application.CreateForm(TDmVisualUtils, DmVisualUtils);
Application.CreateForm(TfrmMain, frmMain);
end;
Application.Run;
One trick I use is to place a TTimer on the main form, set the time to something like 300ms, and perform any initialization (db login, network file copies, etc). Starting the application brings up the main form immediately and allows any initialization 'stuff' to happen. Users don't startup multiple instances thinking "Oh..I didn't dbl-click...I'll do it again.."