Many terminals, including the one with Cache, will respond to specific escape-sequences to hide and show the cursor. For example:
w ! w $c(27),"[?25l" w "Cursor hidden" h 5 w ! w $c(27),"[?25h" w "Cursor shown" h 5 w !
- Log in to post comments
Many terminals, including the one with Cache, will respond to specific escape-sequences to hide and show the cursor. For example:
w ! w $c(27),"[?25l" w "Cursor hidden" h 5 w ! w $c(27),"[?25h" w "Cursor shown" h 5 w !
I'm not aware of a way to do this directly. But in the case of routines (and classes) shown in Atelier Explorer (AE) these are files on your local filesystem. When I switch to the Project Explorer (PE) view, a right-click on a project gives me an option to "Show in Local Terminal", with a sub-option "Terminal". Choosing this gives me a new Terminal tab in another Eclipse pane. I'm working on Windows, and this Terminal gives me a Windows command shell in the root local directory of my project. There I can issue a suitable DIR command, e.g.
dir /s /o-d
For an equivalent on the server I suggest using Management Portal, which can be quickly launched from the context menu of a connection in the Server Explorer (SE) view. Once in Portal you can use System Explorer\Routines, and click on the Date header to sort the list by last modification date/time.
Thanks for the tip Roger. As shown in your example, that dialog also does some clever stuff with CamelCase filters.
I assume you're using 1.1.391 (the latest public release), and that the " - MGH" indicates you have defined an Eclipse working set with that name and selected it (e.g. in the dropdown menu from the down-arrow on that dialog).
For the benefit of others who may not have found this dialog yet, it's on the standard "Navigate" menu and also the standard toolbar (white "C" in blue circle).
It apparently searches the filenames within your projects (optionally limiting this to projects in your current working set), but I haven't yet found a way to make it take the package into account in its lookup, nor to display it.
I am interested to know more about the "Workspace matches" part of your screenshot. So far I haven't managed to get this on mine.
And can someone explain the rather cryptic "TZ = TimeZone" part of the dialog text?
Thanks for a useful webinar. I was particularly interested to hear that there's going to be a focus on making Atelier play better with the "shared development" way of working. IMO, good news for teams that already work that way and until now may have been thinking they'll have to abandon it and get each developer set up to work in their own personal environment in order to adopt Atelier.
Trevor, how does your source control mechanism deal with the way that Portal doesn't by default have any concept of "current project"?
Perhaps the project-related classmethods implemented in %CSP.Portal.SourceControl.Util were implemented for your use-case?
For the record, the following two enhancement requests got raised in Jira last month after I followed up with WRC on this post:
At this point neither has been slated for a particular Atelier release, so if you make use of add-ins or templates from Atelier and want to lobby for these improvements, you know which ATL-numbers to mention.
For the record, my original #2 is logged at ATL-3359 and currently slated for Atelier 1.5. My original #3 is logged as ATL-1934, also slated for Atelier 1.5.
Thanks, I found this technical explanation useful.
Has ISC ever considered implementing switchable compile-time enforcement of this uniqueness?
I agree in relation to Method and Property members. But it seems less clear to me for other sorts of member. For instance, an Index on a Property. Or a Foreign Key declaration for one.
Any news on when we can expect this? It didn't seem to make 1.1.
This didn't work for me. Here's what result contained:
The /D switch is only valid with the /S switch.
Anyway, AFAIK the Read-only attribute of a Windows folder is of limited use. Even if you set it using the attrib command this won't prevent you from being able to modify files within the folder (provided those files don't have their Read-only attribute set).
I think the OP was referring to permissions on the folder, not attributes. And in my testing, even if I explicitly deny Write permission on a folder to my user, the ##class(%File).Writeable(...) method still tells me I can write to a file that's in the folder. Of course, when I actually try to open it for write, the timed OPEN command fails correctly.
See Robert's answers. The %File.Writeable(...) method's underlying implementation ($zutil(140,12,filename,2)=0) is apparently not able to determine whether or not a directory is writeable, despite the method doc stating "Return true if the file/directory is writable and false if it is not"
See this older doc for $zutil(140) information.
You could try raising the issue with InterSystems WRC, but my guess is they'll say it's a bug in the comment on the method.
My reading of the post is that the OP is saying that %File.Writeable(...) on the Windows platform returns the correct answer for a file but not for a directory. I haven't investigated yet.
Congratulations on your latest publication Mike!
Good point Jon. Here's a concrete example, taken from the CheckLinkAccess classmethod of %CSP.Portal.Utils (2017.2 version). I have done the macro expansion myself and highlighted the expansions:
Set tHaveAllRole = 0
Do
. New $roles
. Set $roles=""
. If ($extract($roles,1,$length("%All"))="%All") Set tHaveAllRole = 1
If tHaveAllRole {
...
I just had this happen, but not on Mac. I'm using Eclipse Oxygen on Windows 10 (64bit), with Atelier 1.1.391.
Things were working fine, then I restarted Eclipse and found my connections to servers were failing. When I used "Edit Connection" and clicked the "Test Connection" button I got this:

Restarting Eclipse didn't resolve it, nor did "Check for updates" find anything out of date. So I used Help\Install New Software, chose the repository I'd previously installed Atelier from (https://atelier.artifactoryonline.com/atelier/updates/beta/latest/), cleared the "Hide items that are already installed", then selected both "Core" and "Optional" and clicked "Next". Eclipse reported that most pieces weren't needed, but it did install one, which I think was "TM Terminal via Remote API Connector Extensions".
When it had finished it told me to restart Eclipse, and now my connections worked.
Evgeny was too modest to mention that he excluded himself from the awards on the basis that it's sort of his job to make lots of contributions to DC. The raw data shows just how prolific he is in doing that.
A minor quirk in the table is that "DC Expert 2017 - 4th-10th places" only lists 6 names rather than the expected 7. But looking at the raw data I see that 2 authors tied for the position below Rubens Silva. So I guess either they both get the badge or neither does.
Yes, sometimes the license restrictions that apply to evaluation of a downloaded copy of Cache (i.e. without having contacted InterSystems for a loan key) lead to opaque and unfortunate failures that may give the impression that the product isn't worth the effort.
Thanks, that makes sense. To clarify for others, in the example you gave, Sample.Person was included as an "expanded class" because it's the superclass of Sample.Employee.
The superserver port is recorded in the cache.cpf file, and I think it can be changed there by simply editing the file and then restarting Cache.
I'm guessing that the Cache installer uses the registry to discover the locations of the CPF files it needs to check when picking a "free" port to offer as the superserver port for a new instance. So if one of your instances wasn't properly registered at the time you installed another instance then the installer may have defaulted to a port that was actually already taken.
If you don't already have an online support account (a.k.a. WRC Direct) then I suggest you email your bug report to support@intersystems.com
More info abut InterSystems Support is here.
I also like this style, as it helps me spot the lines where execution at the current level might terminate.
There's some documentation here.
In your case it sounds like a Cache instance was moved onto the server but not added to the registry that Cache's ccontrol command uses. On Windows I think Cache uses the Windows Registry. On other platforms it uses a file, and offers commands ccontrol create, ccontrol update and ccontrol delete to maintain entries in this registry.
Possibly the OP has to work with a version of Cache / Ensemble etc that doesn't support Atelier?
Robert, my understanding of the h:\dev5\ suffix on the error string is that this indicates the directory holding the CACHE.DAT database where Malcolm's webservice class is located. I'm guessing his web application definition in Portal doesn't even have READ permission on that database.
Why not just use the "=" operator to compare your values, exactly as you have written in your examples?
Please mark his answer as Accepted.
I'm not clear what you mean by "access the Class Database". Connect Atelier to the SAMPLES namespace and you'll be able to view/edit classes from the SAMPLES database. Please expand on what else you're trying to do.