Consider, i have a global ^TEST and i want to replicate/have a copy of the same in ^TEST2 automatically.Each action set or kill on ^TEST should reflect on ^TEST2 automatically.
The only way to make sure that this can happen 100% reliably is to create a Journal Filter which watches for changes to ^TEST and then manipulates ^TEST2 appropriately.
See http://docs.intersystems.com/cache20141/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal#GCDI_journal_util_ZJRNFILT for details on how to implement this.
Related
The official docs show me all the ways to replay or filter or transform flows, i.e. network data captures, but it does not show how to simply
So let's assume I save a flow via mitmdump, or – and I guess or rather hope – it is the same file, via save_stream_file (as an command-line option --save-stream-file).
Now can I can I load that again – without replaying, i.e. just to view it?
So think of a collected dumpcap file, I know I can load it in the wireshark GUI. Wireshark itself of course does not re-trigger the requests, just show them, so I can analyse them.
I want to do the same here. How can I do that?
Oh, it seems to be done with the rfile (or -r for short) option (not really an intuitive name, especially when the other option to filter that is called readfile_filter, i.e. not abbreviated).
Also, you do not want to bind a new proxy for that, so to do this, add -n. (This is another option that I could not find being documented, but remembered from some example)
So in the end, here is how to load it in mitmproxy e.g.:
$ mitmproxy --rfile ./mitmproxy-flow.cap -n
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 want to copy a load module from one pds to another using REXX.
You could invoke IEBCOPY from within a Rexx, allocating the appropriate datasets to the appropriate ddnames before invoking IEBCOPY.
I'm unable to provide an example as I don't have the facilities/access.
Note that doing so may tie up your terminal/session.
You could also go into a more elaborate solution to build and submit a batch job, perhaps even having a panel front end, driving file tailoring/skeletons.
As #cshneid said you can use IEBCOPY Using IEBCOPY in rexx is basically the same as in JCL but:
use TSO Alloc to allocate the files
Call/invoke the program
if running under ISPF you can use LMCOPY. Roughly the following should work, you may need to issue a LMOPEN / LMClose on the data-ids as well ???
Address ISPEXEC
'LMINIT DATAID(DIDFrom) Dataset(in.data.set)'
'LMINIT DATAID(DIDTo) Dataset(to.data.set)'
'LMCOPY FromId('DIDFrom') FROMMEM(mymem) toId('DIDTo') toMem(newMemberName)'
'LMFREE DATAID(DIDFrom)'
'LMFREE DATAID(DIDto)'
If running foreground, the ISPF services used to have the advantage as they "co-ordinated" there actions with all other ISPF users- Less likely to corrupt the PDS directory. Not sure if this is an advantage any more.
Using just REXX what you want to do is not possible, however, you can invoke IEBCOPY (or your site equivalent) to perform the task for you.
You may want to investigate calling programs like IEBCOPY and passing it the appropriate control cards to perform your task.
I am writing a custom plugin for TinyMCE. One of the new buttons makes a number of DOM manipulations in the document. The default undo behavior creates a few undo levels in the middle of the changes. If the user hits the undo button after using the plugin, he/she then sees a document with the operation partially reversed and really not in a proper state.
It looks like there used to be a pair of instance commands called mceBeginUndoLevel / mceEndUnoLevel (removed in version 3.3) that let a developer start/end a large undo batch that would be undone in a single operation....but I don't see anything in the docs that replaces that feature.
Some forum postings suggest using editor.undoManager.add() as a replacement, and that works for cases where you want more levels of undo during an operation, but I actually want less.
There is also a undoManager.onBeforeAdd event that you can hook into, but looking at the source for the undoManager, I don't think that hooking there will let you abort an undo snapshot.
So, is there a proper way to batch undo operations that I'm not seeing using the existing API? If not, my only other option seems to be patching the undoManager to allow the onBeforeAdd hook to abort a snapshot.
I suggest overwriting the current UndoManager. It is just a rather small file.
That's what we needed to do in order to suppress the creation of some unwanted undosteps.
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.."