Inserting Carriage Return Into Memo Text (1 Viewer)

[John Big Booty]

I'm currently playing around with a very simple DB to decode text that has been encoded using a very simple transposition cipher.

It all works fine, however I'm having trouble with carriage returns. I'm currently using the following snippet to detect and insert carriage returns, as part of a larger While loop;

If Left(Me.EncodedText, 1) = Chr(13) Then
        Me.DecodedText = Me.DecodedText & Chr(13)
        Me.EncodedText = Right(Me.EncodedText, Len(Me.EncodedText) - 1)
End If

This works fine except that what is displayed in the DecodedText field is a small square box rather than a carriage return.

Is there I way I can get this to actually function as a carriage return for display purposes?

 

[georgedwilkinson]

Use vbCrLf instead of Chr(13). I believe that is both Chr(10) & Chr(13). If not, experiment with Chr(10) alone or combined with Chr(13).

 

[John Big Booty]

Champion That did the trick, I'd tried vbCr but just got the little square.

 

[georgedwilkinson]

Yeah, I spent untold hours figuring that out.

 

[John Big Booty]

You know the strange thing is, if you copy and past that little square box into a Word document it behaves as a carriage return, it just doesn't display as one in the Memo field

 

[Banana]

It's a common issue, unfortunately. In UNIX, the llne ends with a CR only, while in Windows, it's CR/LF combination. With Word, it supports text documents so thus is flexible enough to work with either format.

Another example is when I once copied a SQL script from my vim to SSMS, SSMS warned me of inconsistent line ending after I've edited some SQL to work with T-SQL dialect... of course because when I edited, I (or rather the SSMS) had added CR/LF to file that was littered with CR.

In case of VBA, we have to be explicit as VBA isn't quite at sentient stage just yet. I hear they'll achieve that in few more decades. So if we wanted flexibility, we would have to tell VBA to treat a single CR as if it were a CR/LF so it can process file regardless of how it has their lines ended.

(Tangentially- I vaguely recall this was a throwback to the typewriters... did we have to hit 'return' then another key to feed the line? The one I remember my parents had when I was a kid, I don't think I remember doing that, but I do remember that it was possible to do a carriage return and remain on the same line or feed the line without returning the carriage.)

 

[John Big Booty]

Thanks Banana, that makes a lot of sense.

 

[georgedwilkinson]

When I worked in Unix we had 2 commands: dos2unix and unix2dos (or something like that) for just this issue. Of course back then, everybody was still using Lotus 123 and whatever the database system was back then so there weren't many issues with cells and memo fields.

When I was a kid, the typewriters had a silver handle to do a cr/lf...it did both, just like vbCrLf. You could do a carriage return by manually moving the carriage to the left. You could to a line feed by turning the knob on either end of the carriage.

Don't ask me about spaghetti pickers, the days when a floppy disk would hold more information than a programmer could ever type in a lifetime, or when 64K was sufficient memory to run over 100 terminals at the same time on a business system.

 

[dcb]

(Tangentially- I vaguely recall this was a throwback to the typewriters... did we have to hit 'return' then another key to feed the line? The one I remember my parents had when I was a kid, I don't think I remember doing that, but I do remember that it was possible to do a carriage return and remain on the same line or feed the line without returning the carriage.)

Pretty sure it was the line feed on the typewriters you could do on its own - used to work great when doing "bullet" type layouts....
The electronic typewriters had an additional button for these (top right i think) - so you could do either or the "return" key did both
I feel old now!

PS do you remember the space settings?

 

[John Big Booty]

.........
The electronic typewriters ....

Luxury, we used to dream of electronic typewriters......

Apologies to Monty Python

 

[Banana]

PS do you remember the space settings?

Sorry, afraid not. My brief and limited exposure to the typewriter mainly consisted of being more fascinated with watching the keys hitting the paper rather than what I could do with it. Don't think I remember anything about space setting... Is that to do with how wide a tab can be adjusted?

Luxury, we used to dream of electronic typewriters......

You were fortunate to be able to dream of electronic typewriter. We had to do with dreaming about parchment, quills and candle!

 

[georgedwilkinson]

You were fortunate to be able to dream of electronic typewriter. We had to do with dreaming about parchment, quills and candle!

Stone tablets and chisels, here.

Speaking of watching the keys hit the paper, I used to work on these monster printers made by the Tallarand Company, I believe. We (un)affectionately called them "Tallys". They had a long chain with all the characters on them which rotated around in between the hammers and the paper...when the correct character for a given space was in the right position, the hammer would fire, making an imprint of the character on the paper. They were comparatively fast, at that time, but they were a maintenance nightmare (lots of moving parts).

Ah, the good ol' days.

 

[Galaxiom]

I heard a story about chain printers. I don't know if it was that particular one.
However a programmer decided to demonstrate a vulnerability that the engineers hadn't forseen. The engineers we confident the thing was built so robustly as to be invulnerable.

The hammers are fitted right across the carriage. Multiple hammers can fire simultanously where the chain was correctly positioned for the particular character positions on the line.

The programmer calculated a document that put the chain movement into a mechanical simulation of an epileptic fit and got parts of the machine in resonant motion akin to that famous incident on the Tacoma Narrows suspension bridge.

 

[ChrisO]

Well I don’t understand the original post here but I think it could be done with the Replace function.

As an aside…

Mechanical typewriters had a left mounted arm that produced two effects.
The first was the ‘light touch’ to advance the paper vertically; go to the next line down the paper.
The second was the ‘heavy touch’ meaning to keep pushing the carriage, with the paper, to the right thereby moving the next print position to the left relative to the paper.

Pushing the lever to the right achieved two effects; a line feed down (light touch) and a carriage return (heavy touch) in that order.
(The modern day ASCII equivalent would be a LineFeed Chr$(10) and then a CarriageReturn Chr$(13) and is probably the reason they have those ASCII numerical values in ascending order. {I don’t know.})

So, a single (heavy touch) to the right, in one motion, produced a New Line to the left margin or to the horizontal position where the lever was released.

There are three reasons for this mechanical behaviour.
The first being that the print mechanism was complex and it was easier to move the carriage…with the paper.
The second reason was that the paper was single sheet.
The third reason was that there was no correcting the line above and so a Line Feed was always down the sheet.
(In other words, if you made a mistake on the line above…change the sheet.)
(Correcting typewriters came along much later.)

So far so good for old mechanical typewriters.

Then along came the electrical typewriters (printers) and that made a difference.
The print mechanism became less complex and lighter, well not always.
It became easier to move the print head rather than the carriage which carried the paper with it.
The paper became continuous sheet for computer use, scan fold paper.
Moving continuous sheet both into and out of the typewriters (printers) became the headache.
Computers need precise vertical paper positioning.
Tractor feed was the answer.
Tractor feed margins need to be removed after printing.
Tractor feeds are a weak attachment to the paper for removal.
The paper needs to travel vertically, without horizontal force, because of that weakness.

Back to square one.

The printer must move the print head rather than the paper on continuous sheet feed.
It’s required to be fast and paper jams would be horrendous it not so.
(Bad enough as it is without moving the paper.)

The mechanical ASCII sequence of LineFeed Chr$(10) and then a CarriageReturn Chr$(13) is replaced by CarriageReturn Chr$(13) and then LineFeed Chr$(10).
(It’s faster to issue the LineFeed Chr$(10) after the CarriageReturn Chr$(13) because the LineFeed can be done during the CarriageReturn.)

The need for speed.

Then along came the Line Printer.
Neither the carriage, there is none, nor the paper move horizontally.
The characters are on a continuously rotating drum.
The print head is replaced by (usually) 132 lightweight hammers.
(This can move slightly horizontally but (again usually) only by one character spacing on the character print drum.)
Ink ribbon moves horizontally from supply spool to take-up spool.

They print quickly; they make a lot of noise.

CarriageReturn/LineFeed pairs started off being LineFeed/CarriageReturn pairs but were reversed for speed.

Hmmm: -
Try the Replace() function…

 

[Galaxiom]

I come from the typewriter generation and as I have always been interested in mechanical devices I remember how they worked quite well.

The Carriage lever was on the left. Pushing it toward the right rotated the platten to advance the paper. The line spacing was a stop that set the distance it could move. Continuing to push the lever moved the carriage along.

Margins were moveable stops. Tabs were done with a row of pins that were pushed up to set stops.

The shift key on some moved the entire type mechanism including the keys down so the other half of the type on the moving arm hit the ribbon. "Caps lock" was called Shift Lock and simply prevented the mechanism returning to the lower case character position. Others lifted the platten slightly.

I still remember my wife asking me why the number keys didn't lock to the special characters when she pressed the Shift lock on our first computer keyboard. She was a two finger typist and did all her special characters and capitals using the shift lock.

 

[Galaxiom]

I also remember a line printer on a Digital PDP11-34. If I remember correctly it had a 132 column dot matrix configuration. Dot matix was originally 9 x5 dots per character so potentially the thing had a hideous number of pins. I remember it was horrendously noisy despite being under a cover.

 

[ChrisO]

Yes, well fun can be had with that (Post #13).

If we want to put a name to it, it might be sympathetic resonance.

Three things are required: -

It needs a printer with a horozantall moveable print head, preferably 132 columns.
The print head needs to be servo-driven in both directions to achieve constant acceleration.
We need to write a small program…

Send print position to column 1.
Send print position to column 132.
Send print position to column 2.
Send print position to column 131.
Send print position to column 3.
Send print position to column 130.
Send print position to column 4.
Send print position to column 129.

Repeat to destruction…

 

[Galaxiom]

The one the programmer did was particularly clever in that it was simply a text document. All the characters are distributed along the chain and by choosing particular sequences the chain could be made to do as you described with the print head. But the chain being much heavier than a print head worked much better.

This also reminds me of an old virus I heard of but never saw. It was supposed to play the 1812 overture on the floppy disk drive using head movements. Nyeeeet, Nyeeet, Nyeeet, Nyeeeeee. etc

It was said it could burn out the head servo if left to continue. One of the few virusses that could actually destroy the hardware itself.

 

[ChrisO]

I doubt if that could be achieved with a chain printer since, apart from the heads, there is no reciprocating mass.

Technically speaking, a high-speed printer must not exhibit reciprocating mass, else it would not be a high-speed printer or it would consume too much power to achieve it.

---

The idea that a virus might cause hardware damage is not new and in fact one example was actually a failure of the original ACIA chip even though the problem was not a virus.
At first construction, subsequently fixed mind you, the chip could be set to a high Baud rate that would untimely fry it.

The problem was not the quiescent state power consumption but rather the frequency at which it traveled from one quiescent state to another. TTL and ECL logic does exhibit comparatively large amounts of quiescent state power consumption. On the other hand, CMOS circuits consume near to nothing in the way of power at rest due to their high impedance. Their main power consumption comes from the power dissipation required to raise their junction voltage to the switching levels (a function of gate capacitance {inrush/outrush current}) and the drain current while doing so.

These days, power consumption, and therefore heat, is generally a factor of switching rate (frequency), gate density (junction size, junction capacitance and heat dissipation) and not quiescent state power.
(Ask an over-clocker.)

 

[Galaxiom]

The chain printer was described to me by a toolmaker. He wasn't involved in the design. He said the chain travelled continuously in one direction and the hammers hit it at the approriate time. So I guess that is how it managed high speed.

He thought the special document somehow caused the slack in the chain to suddenly relocate from one end of the machine to the other.