Voted! Nice write-up, thank you Jean. (boy .. the MS community pages don't work nearly as well as the InterSystems D.C.!) Have you considered posting your content above in the appropriate MS Discussion Forum for PowerBI in order to drum up some more support? It is very well articulated :)
Great work Developer Relations Team!! It was a great conference and it was wonderful to see so many people connecting on so many different levels. The culture is contagious :) We all appreciate your hard work!
if you are wanting to completely render the page within the context of another page, then using <iframe src="package.page.csp" </iframe> is going to be your best bet. Remember that a csp page isn't just a static HTML snippet - it is an entire renderable page, along with pre-page headers, etc. That is why OnPreHttp(), OnBody() and OnPostHttp() are all included in the page framework for a .csp. If you simply want to show what is 'rendered' when you call the page directly, you can play with calling OnPage() (which contains the compiled version of the entire body of your .csp file), but that may not operate correctly when called in isolation - it is intended to be called as part of a full pageload process, which the iframe approach above would provide.
just like you would call any class - "write ##class(csp.package.page).method()"
It's been a while since I had to look these up. You probably have to select the option for 'show generated code' order to find it. Unless you overwrote the default package, they should show up as csp.****.cls classes (in the "csp" package)
the .csp file compiles into a subclass of type %CSP.Page. When it is called, on the back end the various methods of the subclass of %CSP.Page are involved in order to stream the content of the .csp page. Please see the documentation link above for more details.
Actually, you should read this doc: https://docs.intersystems.com/iris20241/csp/docbook/Doc.View.cls?KEY=GC…
there are other callbacks you will need to call besides OnBody(). Make sure to call them in succession to get full page functionality.
look at the generated class from the csp. you should be able to call the OnBody() method to create the text stream containing the html
a CSP page will actually compile into a .cls, so you can call specific methods of your CSP page by calling the method using ##class(mycsppackage.mycsppage).methodname() (the csp package name is configurable but defaults to 'csp')
thank you @Eduard Lebedyuk ... this is an interesting approach. Unfortunately, a couple of the globals I need to override for Bar are top level %ALL mappings, but others are subscripts so I may be able to cut down my custom coding using this approach.
LOL - great comment Robert :)
it sounds like this is an Epic provided example, so presumably ConvertToMTime is defined by Epic but was either misspelled or called from a context where it couldn't be found
I want to re-iterate what Evgeny said ... you should never store your persistent objectscript class definition in source control without the storage definition block. Doing so will cause the storage block to be regenerated from scratch each time source is loaded, and if there is existing data you may have a mismatch of where properties exist on disk and where where the source thinks they should live
as am I!
From your initial screenshot:
.png)
Perhaps you need to be on the 'filerodev2023' Instance, rather than the 'IRIS' instance and you show above on your HOME4 node?
in the screenshot above you are trying to run the class in the FILERO Namespace. Did you try running that command in FILEROIRIS?
@Alexandra Mirzac - welcome to the Community :) I would suggest the following:
1) Make sure you have saved and compiled your class, and that it returned with no errors.
2) Make sure when you are testing in Terminal you are connected to the correct Instance and the correct Namespace
3) Double-check spelling and case in your Terminal command compared to your compiled classname
Please try those things out and let us know if that moves you forward.
glad you figured it out!
Well done and well explained - thank you!
Nice! Thank you for taking the time to figure this out and write it up! I am sure it will be usable by others in the D.C. :)
great summary - thank you for compiling :)
Congrats to the winners - thank you for your contributions :)
great!!
I don't have access to an active HS environment at the moment, but from testing the last part of your query, it looks correct to me. You are saying with the query that has the literal timestamp you get results, but with the 2nd query which targets the prior 2 hours you are getting no results? are you sure that there are records in that time window to fetch? What happens if you change it to a 24 hour window (-24)?
I would suggest someone open an Issue in the GitHub project to formally request this - https://github.com/intersystems-community/vscode-objectscript/issues
Can you explain what you mean by this? "it only leaves me specifying the exact time" It makes it sound like you are using a UI of some sort? Assuming that is the case, you should be able to access the records directly from the underlying table using SQL. If you tell us specifically what table you're trying to look at we may be able to be more specific in a recommendation.
If you go to the class documentation for the %SYS Namespace, are you able to see the Common class? If not, then you may need to reinstall Ensemble in order to get it back.
Glad to hear that you were able to get to the root of why you couldn't see the other classes!
Thank you Tim!!
These classes are still in your 2018.1 instance (if they were not you would not be able to log into the System Management Portal), however, the Security.* package only exists in the %SYS Namespace (as it is not a % package it isn't projected to other namespaces). See: https://docs.intersystems.com/ens201817/csp/documatic/%25CSP.Documatic…
It may have been that you used package mappings to make the Security.* classes available in your application namespace, or that they were mapped by the product (I don't remember - 2014 is 10 years old at this point ;) ). However, best practice today is to change to temporarily change to the %SYS Namespace in your code if you ever need to call the Security.* package. There are privileged calls in there which you typically don't want directly accessible within your application namespace.
@Scott Roth - there was an issue found with the HSHC 2024.1 kit so it was pulled down and a corrected kit should be available in the near future. So sorry for the inconvenience.