I am using the view() function to open an ascii file from the shell, but it opens the file in the form/window in Virtuoso looking at the tail end of the file. EG if the ascii file is larger than the viewing window, the contents scroll down to the end of the file. Is there a way to use view() to open an ascii file but have the first view in the Virtuoso window remain at the head end of the file so the user can then scroll down instead of up?
Also, how can we create a path to write to a file location and pull from a specified path location by getting a path string from dbFullPath() and modifying it?
I am creating a new file using the cell name retrieved from geGetEditCellView()->cellName, but want to write to the same path location returned by dbFullPath() - with the exception of the last directory location.
For example, dbFullPath() returns ".../MyLibrary/MyLayout/layout/layout.cdb"
I create a file called "MyLayout_newfile" and want to write to ".../MyLibrary/MyLayout/MyLayout_newfile"
How do I truncate the end of the path returned by dbFullPath() - losing the "/layout/layout.cdb" portion?
What version are you using? The view() function doesn't do that for me - it shows the beginning of the file - the case it wouldn't by default is if you are passing t as the fourth argument to view(), and then updating the file after initially viewing it (the fourth argument is the auto-update flag, to "tail" the file live).
For your second question, I guess you're after geGetEditCellView()~>cell~>writePath
Given any path like /a/b/c/d/e, you can use the following:
path="/a/b/c/d/e"rindex(path "/") "/e"substring(path 1 strlen(path) - strlen(rindex(path "/"))) "/a/b/c/d"
In reply to Andrew Beckett:
My apologies and thanks again Andrew.
I am using v 5.1.41, and I think you are correct about the autoUpdate being responsible for this. When I use view(MyLayout_newfile), the form/window opens with the correct title, but is blank. So I was following the view() call with hiEnableUpdateWindowCB(), and this updated the window with the file contents, but scrolled to the tail (almost every time but for some reason not every time...and did not matter if the file already existed or not).
So this begs the question, how do I get my file contents to load in the window without forcing it with the hiEnableUpdateWindowCB() func?
And - geGetEditCellView()->cell->writePath is just what I wanted - thanks!
In reply to jaleco:
I don't really see why you should have to use hiEnableUpdateWindowCB(). Presumably you haven't finished writing to the file before you view it? Could you make sure the file is written, the output port closed, and then view it?
Otherwise there's also hiScrollWindowToIndex(hiGetCurrentWindow() 0) which could be used to scroll back to the top - but that sounds clunky...
Yes, it is possible the view() func is trying to load a file before it is written.
Here is more sample code:
ipcBeginProcess(strcat("shellscript" MyLayout_newfile)) ; creates output ascii file MyLayout_newfile_out in shell env
What code can I use to make sure the file is written, and the output port closed before viewing it?
In reply to dmay:
FYI after experimentation, I am currently using :
ipcKillProcess(ipcBeginProcess(strcat("myshellscript " MyLayout_newfile)))
This seems to work, but takes several seconds (5-10) to return the final viewing window, whereas the hiEnableUpdateWindowCB() func had immediate results despite loading in the file in tail view.
ipcCloseProcess(ipcBeginProcess(same as above) and ipcWait(ipcBeginProcess(same as above) did not work....
The delay of the ipcKillProcess(ipcBeginProcess()) is frustrating enough to consider (while() or until()) creating a comment popup form telling the user that background processes are running...tic tic tic... until they complete, then delete the comment form before displaying the file view window.
I don't think ipcKillProcess is what you want. Surely ipcWait(ipcBeginProcess(...)) is what you want.
Or you could use the optional exit callback on ipcBeginProcess() - 6th argument I think - to do this.
ipcWait(ipcBeginProcess(...)) never returns....and keeps my Virtuoso session suspended in the meantime until I kill the icfb process at the shell.
But it does usefully (!) display the following in the CIW:
"Waiting for ipc: [id#] to terminate"
over and over again....
I do not see an exit callback argument on ipcBeginProcess()....there is an optional [tsu_postFunc] argument - is that it? If so, can you suggest what to use for this?
I think the problem I have is in the shell script, not in the SKILL code. The shell script was written to write to a file output but also to the shell, and the output to the shell is unable to complete its operation...this is what I can surmise. So until I can rewrite the shell script to avoid shell output, I will rely on the ipcKillProcess() func and then test ipcWait() once more.
Thanks again for your help.
The postFunc arg is the one I meant, but it's definitely not going to help if the child process is not actually exiting. That's the problem you have to solve.
The challenge with using your ipcKillProcess() approach is that you are extremely susceptible to the time it takes to run. If the child process takes slightly too long, you may have killed it before it did anything yet...
The horribly sloppy way of solving this is to:
Or fix the script and spend the rest of the time that you would have spent implementing and debugging the above in the pub.
Thanks again for the info.
I will opt for fixing the script and a Bass!