What is the issue if we use text1 =text2? What is the right method to copy text between two text variables? - ewam

I am getting error in compile mode for the statement text1=text2. What is the issue with the statement and how can we resolve it?

There is a section in the Wynsure Development Rules dedicated to this question, look for the section "14.3 Texts" I'll summarize:
A text variable is a pointer to a buffer that gets automatically reallocated as we write to the text, therefore the memory location differs as the text grows, changes or shrinks. For this reason the pointer isn't contant. eWAM automatically allocates a new larger buffer and copies the content of the old buffer to the new buffer, frees the old buffer and then updates the MyText pointer to point to the new buffer.
Shallow Assignment
It is the most dangerous operation if you really do not understand how text variables work.
For example the following code will crash (as a general rule what will cause a crash is either accessing to a memory location that has been freed or freeing the same memory location twice.)
MyText2 = MyText1
Write(MyText1, ….)
Blank(MyText1)
Blank(MyText2) // Crash
The shallow assignment MyText2 = MyText1 simply copy pointers. It does not duplicate buffers.
When copying a text from one variable to another one, use a deep copy :=
If you use = it points to the original text var address. And then when you set the second text to blank, it in fact sets the original text to blank (dispose).
Dedicated Text Methods
Text has a number of custom methods that handle them correctly such as the var.type.write function
var.type.blank function
Procedure Test
var tmpText : Text
tmpText.type.Write(‘Hello’, #tmpText)
tmpText.type.blank(#tmpText)
endProc
Note that we always need to blank the old variable text after we move the content so that there isn't a memory leak.
procedure AnotherProcedure
Var MyText : Text
Var tmpText : text
tmpText= GetXXXText
Write(MyText, tmpText )
tmpText.type.blank(#tmpText)
endproc

Related

How to read DICOM private tags without reading/loading pixel data?

I would like to read DICOM private tags. These private tags are under hexadecimal tag x7fe11001.
I know one of the pydicom configurations that read till pixel data starts (so the memory is not loaded up).
pydicom.dcmread(raw, defer_size="2 MB", stop_before_pixels=True)
But the private tags I am trying to read are after the pixel data. So I am ending loading complete file in memory which is not optimal. What are the other ways to read it in an optimal way?
I know there is a config param for the above method, called specific_tags. But I could not find any examples of how to use it.
Any suggestions to read DICOM metadata without loading pixel data into memory would be awesome.
You are right, specific_tags is the correct way to do this:
ds = pydicom.dcmread(raw, specific_tags=[Tag(0x7fe1, 0x1001)]
In this case, ds shall contain only your private tag and the Specific Character Set tag (which is always read).
As DICOM is a sequential format, the other tags still have to be skipped over one by one, but their value is not read.
Note that you can put any number of tags into the specific_tags argument.

IE10 / Edge PDF not showing correct values

So I have a PDF that has been created on the fly by opening a template, modifying the values for certain fields, and then saved.
Works:
If I open the file in Chrome, I have the correct values.
If I save the file to disk and open it with Adobe Reader DC (or whatever that's called), I get the correct values.
Doesn't Work:
When I open the document in IE 10, it opens in Edge, and shows "default" values for the fields.
When I save the file to disk and open it with IE, it shows "default" values.
When I open the file using "PDF reader - Document Viewer and Manager" it shows "default" values.
I'm using Windows 10, the application I'm working on is done in ASP.Net. It works the same way whether I return a FileStreamResult, FilePathResult, or File.
And I'm now pretty much certain the problem is Microsoft's products and not my code.
Any idea why Microsoft products are incapable of opening my PDFs correctly? Do they have to be flattened in some specific way or something?
Edit (more information as requested in comments):
The documents are created using PdfSharp.
They have fields that are dynamically replaced with values (i.e. [MyFieldA] is replaced with "ActualValueA").
Once the merge fields are replaced with actual values, the file is written using File.WriteAllText(fileName,fileText); where fileText is obtained through File.ReadAllText(fileTemplateName);
Image of comparison of fields that are wonky:
So I found the solution to the problem, and it appears that it might be a two-fold thing.
One piece of the puzzle I believe was the memorystream being used to create the PDF. It was declared in an inner scope, used in a PdfReader.Open call in an assignment to a var that was declared in an outer scope, and then the scope ended, while the var was still being used. I moved the memorystream declaration to the outer scope where the var declaration was so that they would be in the same scope. Also, the memorystream wasn't being closed with a memoryStream.Close() call or in a using (var memoryStream = new MemoryStream()) { } block. So I added a call to memoryStream.Close().
The other piece is that the PDF template form fields had some default display values. It appears that Microsoft stuff (Edge, PDF Viewer) may not be able to get the inserted values, and is instead reading the default display values of the fields and displaying those. Once all of the default display values were removed, Edge began opening the PDF and displaying values correctly.
Since these two pieces were done in tandem, I can't say for certain that they both play an equal role in this, but these are the only two changes that were done to get values to start displaying correctly. My gut feeling is that the problem lies with the default display values and Edge.

What Exactly are Anonymous Files

A passage in the file documentation caught my eye:
## We can do the same thing with an anonymous file.
Tfile <- file()
cat("abc\ndef\n", file = Tfile)
readLines(Tfile)
close(Tfile)
What exactly is this anonymous file? Does it exist on disk, or only in memory? I'm interested in this as I'm contemplating a program that will potentially need to create/delete thousands of temporary files, and if this happens only in memory it seems like it would have a much lesser impact on system resources.
This linux SO Q appears to suggest this file could be a real disk file, but I'm not sure how relevant to this particular example that is. Additionally, this big memory doc seems to hint at a real disk based storage (though I'm assuming the file based anonymous file is being used):
It should also be noted that a user can create an “anonymous” file-backed big.matrix by specifying "" as the filebacking argument. In this case, the backing resides in the temporary directory and a descriptor file is not created. These should be used with caution since even anonymous backings use disk space which could eventually fill the hard drive. Anonymous backings are removed either manually, by a user, or automatically, when the operating system deems it appropriate.
Alternatively, if textConnection is appropriate for use for this type of application (opened/closed hundreds/thousands of times) and is memory only that would satisfy my needs. I was planning on doing this until I read the note in that function's documentation:
As output text connections keep the character vector up to date line-by-line, they are relatively expensive to use, and it is often better to use an anonymous file() connection to collect output.
My C is very rusty, so hopefully more experienced people can correct me, but I think the answer to your question "What exactly is this anonymous file? Does it exist on disk, or only in memory?" is "It exists on disk".
Here is what happens at C level (I'm looking at the source code at http://cran.r-project.org/src/base/R-3/R-3.0.2.tar.gz):
A. Function file_open, defined in src/main/connections.c:554, has the following logic related to anonymous file (with an empty description), lines 565-568:
if(strlen(con->description) == 0) {
temp = TRUE;
name = R_tmpnam("Rf", R_TempDir);
} else name = R_ExpandFileName(con->description);
So a new temporary filename is generated if no file name was supplied to file.
B. If the name of the file is not equal to stdin, the call R_fopen(name, con->mode) happens at line 585 (there some subtleties with Win32 and UTF8 names, but we can ignore them now).
C. Finally, the file name is unlinked at line 607. The documentation for unlink says:
The unlink() function removes the link named by path from its
directory and decrements the link count of the file which was
referenced by the link. If that decrement
reduces the link count of the file to zero, and no process has the file open, then all resources associated with the file are
reclaimed. If one or more process have the
file open when the last link is removed, the link is removed, but the removal of the file is delayed until all references to it have
been closed.
So in effect the directory entry is removed but file exists as long as it's being open by R process.
D. Finally, R_fopen is defined in src/main/sysutils.c:135 and just calls fopen internally.

Print plain text to printer (paper)

I have a QPlainTextEdit widget that holds text that the user entered. The text might contain \n characters or it may all be on one very long line. My objective is to print this text on a printer (on paper) with word wrapping. The functions QPlainTextEdit::print() and QTextDocument::print() are not suitable to me because they both print the page number at the bottom of the page, which I don't want, and second, I can't seem to be able to control which pages to print (for example if the user only wants to print page #2 out of 5 pages) - the entire document is always printed.
Basically I am using a QPainter object to paint the text on the printer. The main difficulty I am facing is determining when to call QPrinter::newPage() function. How do you determine how much text will fit on a page? If the text is on one long line and the line is being word wrapped, how do you know when the first page is full and when to start a second page? I use the following code to draw:
painter.drawText(printer->pageRect(), Qt::TextWordWrap, ui->plainTextEdit->toPlainText());
painter is of type QPainter; printer is of type QPrinter; plainTextEdit is of type QPlainTextEdit.
To get the vertical size of your text, call painter.boundingRect( painter.window(), myText ).height();. When that exceeds painter.window.height(), it's time to call newPage().
Now it's just a matter of building up your text word-by-word until the boundingRect height exceeds the page height. I'd suggest keeping a "safe" QString that you know will fit on a page and an "unsafe" QString that you just added the new word to. If the new word didn't exceed the height, then assign the safe string to the unsafe one. (Qt has some optimizations like shared copying to keep this from being too compute intensive).
To deal with individual words in a QString, you'll want to play with indexOf() or split() using their QRegExp variants so you can search for whitespace like spaces, tabs, newlines.
You'll have to account for a single "word" that itself won't fit on a page, and split it up mid-word. There may be other devils in the details but hopefully that gets you a good start.

append text into the beginning of a textfile

Is there a way that I can always append new text into the beginning of a text file in Qt? i'm using QFile::Append to do it.
file.open(QFile::Append | QFile::Text)
You can't, see the documentation at http://doc.qt.io/qt-5/qiodevice.html:
QIODevice::Append 0x0004 The device is opened in append mode, so that all data is written to the end of the file.
The problem is even worse, a file is usually stored sequentially on disk, appending (better: inserting) at the start of a file would involve moving all data towards the end of the file, thus a reorganization of filesystem blocks. I'm not sure such a filesystem exists, but if, I guess it would only allow insertion of a multiple of the filesystem block size into a file.

Resources