Sergey - I also appreciate the point about the "component" approach (as we're using 1.x + Angular Material). If you have any good references or tutorials on that approach (and/or contrasting with the 'typical' approach to do Angular 1.x), please post them :)
Gaolai,
You need leading whitespace on any line of a routine which is not a line tag. Try putting a space or Tab on your 2nd and 3rd lines.
Also, "Hello there!" isn't a valid COS command. Try using:
Write "Hello There!"
I think this would be a great approach Evgeny!
If we change the unanswered query to only include questions with 'true' answers selected, do we expect everyone to be good enough citizens to go back and select true answers once they are provided? Would admins be able to mark true answers if the author abandons the thread?
Removed as requested (although I personally think that the screenshot makes people more likely to take a look at your code rather than less likely).
Well played Fabian :) Merry Christmas to you as well!
For debugging or programmatic purposes? If debugging / interactive you can just zwrite the variable to see the properties.
Nice sample Fabio - thanks!!
Michael - thanks for the article. It would be really helpful if you could add a paragraph at the top explaining what the Ensemble scheduler is and what it's main use-cases are so that people can tell quickly whether or not this is something which they would want to learn more about. Perhaps as an Intro?
%ZNODENAME appears to be a statically linked callout function (see http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…). This is specific to your code / application / environment and isn't something generic to Caché.
If you are interested in retrieving your server name, try using:
$piece($system,":")
I think that may be a custom routine. I don't recognize it as a Caché-supplied resource.
My guess is that you are passing data somewhere as a string (because that is around the string limit). You need to use streams instead to store the uploaded file.
Assuming you are a supported customer, you can download this from the Distributions page in the WRC application.
This is not a Caché utility - it must be supplied by your application partner. Also, the AP must be storing their own users at the application level because if they were using Caché users there would be no way to create a utility that shows Caché users' passwords (see Patrick's answer below).
I suggest you reach out to your application partner with this question (or if it is an inhouse development, speak with the development team)
Use Find In Files:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
Sorry - I missed that.
Getting the "When" is easy - there is a timestamp in the header of the generated .INT code showing when the source was last compiled. E.g:
;Sample.Address.1
;(C)InterSystems, generated for class Sample.Address. Do NOT edit. 10/27/2016 09:12:38AM
;;7A2F686C;Sample.Address
;
However the "Who" might prove to be more challenging. You might be able to accomplish this with a Method Generator that records the $Username and timestamp for access via a method or parameter? See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
You can add logic in %OnAfterSave() for your object which will grab the object ID, $Username and the timestamp and tuck them away in an auditing table somewhere. Alternatively you could add LastChangedBy and LastChangedTimestamp properties to your object and then populate them inside of %OnAddToSaveSet() (this is probably the most straightforward way to do it).
Hope that helps!
(credit to Anthony B)
Paul,
Have you looked at the details in the Caché SQL manual about optimizing performance:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
Play particular attention to the section about using TuneTable to properly set the meta-data around table extent size, selectivity, etc. Lot of people miss this and it's very important because the query plans rely on this metadata to optimize performance.
I second the motion!
Excellent idea to post this John - this isn't necessarily common knowledge but it is really useful to know!
Anyone who doesn't need to support 2016.1 code should just use the new syntax. This is intended as a 'bridge' solution to allow a code-base to run on both versions, and then after the code no longer needs to run on 2016.1 the macros should be removed when it is convenient.
Caché Object Script is a super-set of Mumps. If you really want to know the differences you should look at the Mumps standard and know that anything you find in Caché which is not in the Mumps standard can be considered unique to Caché ObjectScript.
Hope that helps.
There are a couple of articles on OAuth 2.0 which might be of interest:
https://community.intersystems.com/post/cach%C3%A9-open-authorization-f…
https://community.intersystems.com/post/cach%C3%A9-open-authorization-f…
Hope that helps!
I think I better understand now - you want 'other' tabs to dynamically update (without the user hitting Refresh) if the user changed namespaces in a separate tab, is that correct?
I think there are probably Javascript events that fire when a tab comes back into focus (you'd have to check) and you could use those to trigger a call to the server to see if the namespace has changed - if it has then redraw the tab to show the context of the proper namespace. It would have more moving parts but it should be possible if you really want to do it.
Good luck!
Playing around with it a little bit, I came to the following conclusions:
- *some* pages rely on the $Namespace url parameter in order to initialize what namespace it is pulling data from
- this doesn't appear to be stored in the session (and therefore it isn't shared between tab); I think it is only effective in the url
- there are some pages which don't honor the $Namespace url parameter (e.g. they still show %SYS even if $Namespace is defined to a different value); this is probably because those pages don't act on any namespace-specific data (or they act on data which lives ONLY in %SYS)
It sounds like if you want to keep your tabs in sync, you should put something in the session, and switch namespaces in your page logic. Probably in OnPreHttp (although you'd need to test to make sure that the namespace sticks for the OnPage method as well)
Laura,
Unless you are using web sockets, whenever someone makes a request from a web client it will issue a call back to the Caché server and it will be handled by a csp process which will spin up and go to a namespace and get the appropriate session variables, etc. If I understand properly what you are looking to do, you could store the namespace as a session variable and then on each of your pages you can test the session variable on the request and reset to a different namespace if it isn't the default. I believe that this is how the SMP does it (or something very similar).
HTH,
Ben
Mike - it would be helpful if you hyperlink to "Newbie's Corner Index"
Matthew - I can replicate what you see on b721 with my unit tests class that I wrote. I'll do some digging and get back to you with what I find.
That is a really old build from before the JSON changes were put in place. Could you please do any testing with the macros on the released version of 2016.1 or the latest 2016.2 FT (https://wrc.intersystems.com/wrc/BetaPortal20162.csp). Let me know if you find any issues there.