I am having a problem copying the contents of a memo to a richedit component.
I thought it would be
Richedit.text := memo.text;
However if I use this the Richedit starts a new line when the memo text wraps to a new a new line (not CR/LF) but just wrapping. The richedit also starts a new line when the memo starts a new line which is fine.
Anyone got any idea's how to copy the text from a memo into the richeditbox without the lines breaking in the Richedit when the memo text wraps
Thanks
Colin
When I do
RichEdit1.Text := Memo1.Text
the virtual "line-breaks" of the Memo1 are not magically converted to line-breaks (CRLF) in the RichEdit, and they shouldn't be. These "line-breaks" are not stored in the memo text buffer. Indeed, the official Embarcadero documentation states
Set WordWrap to true to make the edit control wrap text at the right margin so it fits in the client area. The wrapping is cosmetic only. The text does not include any return characters that were not explicitly entered.
Anyhow, an alternative way is to do
RichEdit1.Lines.Assign(Memo1.Lines);
although this will preserve the virtual line-breaks, as commented below.
Update
Most likely you have some other strangeness (bug) in your code, or you have phrased your question in a too vague manner. However, to eliminate the risk of any problem with the VCL wrappers, try this:
procedure TForm4.FormClick(Sender: TObject);
var
buf: PChar;
const
MAX_BUF_SIZE = 65536;
begin
GetMem(buf, MAX_BUF_SIZE * sizeof(char));
Memo1.Perform(WM_GETTEXT, MAX_BUF_SIZE, buf);
RichEdit1.Perform(WM_SETTEXT, 0, buf);
FreeMem(buf);
end;
As a dirty hack, could you switch off word wrap on your memo then do the assignment and then switch word wrap back on? It's a nasty hack but it might do the trick for you if there is some odd behaviour.
Related
I'm using TSynEdit as a more user-friendly TMemo, mostly for the advanced shortcuts, UNDO/REDO, and so on.
Other things are OK, except the wordwrap behavior, please check the attached screenshot below, SynEdit has a strange space shown on the left-most side.
How to avoid that and make it look like TMemo?
The TSynEdit's key property settings:
synEdit1.UseCodeFolding := False;
synEdit1.Options := [eoAutoIndent, eoDragDropEditing, eoEnhanceEndKey,
eoGroupUndo, eoScrollPastEol, eoSmartTabDelete,
eoSmartTabs, eoTabsToSpaces];
synEdit1.ScrollBars := ssVertical;
synEdit1.TabWidth := 4;
synEdit1.WantTabs := True;
synEdit1.WordWrap := True;
synEdit1.FontSmoothing := fsmNone;
This is not a complete, tested answer to the q, but may offer the determined
reader a jumping-of point to a functional solution.
The word-wrapping behaviour of a TSynEdit is determined by its current
TSynWordWrapPlugin. The default plugin is defined in SynEditWordWrap.Pas
and contains the procedure TSynWordWrapPlugin.WrapLines method, starting at
line 512 in the version I downloaded yesterday using the D10.2.3 GetIt Manager.
Starting at line 560 there is the block of code which, as far as I can tell,
accounts for the space at the start of each wrapped line as illustrated in the q:
if Editor.IsWordBreakChar(vRunner^) then
begin
vRowEnd := vRunner;
break;
end;
Dec(vRunner);
vRunner and vRowEnd are among a number of PWideChar variables used in the WrapLines method.
Watching the behaviour of this code, which is inside a while loop (which is looking for a place to do a word-wrap), it operates
so that when Editor.IsWordBreakChar(vRunner^) returns true, the vRunner pointer
has already moved backwards past the word-break char, which is why it (the space) ends
up on the following line, causing the problem noted by the OP.
Changing the code to
if Editor.IsWordBreakChar(vRunner^) then
begin
{ma} Inc(vRunner); // WARNING: not fully tested
vRowEnd := vRunner;
break;
end;
Dec(vRunner);
forces the vRunner pointer forwards past the word-break character so that the space is included at the end of the line rather than at the start of the next one, so the SynEdit
then displays its wrapped text like the standard TMemo.
Personally, I would not use this change, but would instead see if I could persuade
the SynEdit developers to provide an official solution. if I did use the change
shown above, I certainly wouldn't do it by changing the source of SynEditWordWrap.Pas,
I would do it by writing a replacement for TSynWordWrapPlugin and I would include a check that the inc(vRunner) does not exceed the valid bounds of the buffer being used to do the word-wrapping.
(Someone edit the title if you can understand and define my problem better.)
The problem which I am having is with style formatting of a RichEdit "reverting" back to the default "nothing" aka [] and then back to whatever I set it to, bold or italic for example.
The thing that is at fault - I assume, since I have no idea how it is breaking things - is a procedure (REMainLinesCheck) that checks for amount of lines in the RichEdit and deletes the first one until a certain point is reached (to show a maximum of 14 lines at once) like so:
while REMain.Lines.Count > 14 do
REMain.Lines.Delete(0);
I have 6 occurrences of the above procedure in other procedures that add lines to the RichEdit, but none of them change RichEdit.SelAttributes.Style but one, which was adding only one Bold line like so:
REMain.SelAttributes.Style := [fsBold];
REMain.Lines.Add('something');
REMainLinesCheck;
So I have removed all occurrences except that one and started poking around, it didn't take long to see that it was working in fact fine, regular and bold lines where being added normally and excess lines where being deleted - no problems. But as soon as I reintroduced REMainLinesCheck procedure into another procedure (for clarity purposes, lets call it Proc3Lines, because that's what it does: adds 3 lines and then calls the check for excess lines), every line that follows this Proc3Lines that should be Bold is not... From what I have experienced here it seems that REMainLinesCheck does something in Proc3Lines, since without it everything is fine.
Obviously it's not a circle of procedures that call each other, but the other parts of the code have nothing to do with this RichEdit, not to mention that I don't change RichEdit.SelAttributes.Style anywhere for REMain except that one place that I have shown, there is another RichEdit in the same unit that I do change its line's style like that, but that cannot possibly be related in any way... could it? (No it does not, I just checked.)
Basically: what the hell Delphi? It cannot get any simpler than this and I am still managing to fail, can someone explain and/or fix this? Ask questions, I'll elaborate as much as I can if something is not clear.
To apply a format to a new added line, use the following:
procedure TForm1.Button1Click(Sender: TObject);
var
LineIndex: Integer;
begin
LineIndex := RichEdit1.Lines.Add('Something');
RichEdit1.SelStart := RichEdit1.Perform(EM_LINEINDEX, LineIndex, 0);
RichEdit1.SelLength := RichEdit1.Perform(EM_LINELENGTH, RichEdit1.SelStart, 0);
RichEdit1.SelAttributes.Style := [fsBold];
end;
This has worked for me:
procedure TformStart.Proc;
var
endtxtpos: integer;
begin
endtxtpos := Length(REMain.Text);
REMain.Lines.Add('something');
REMain.SelStart := endtxtpos-(REMain.Lines.Count-1);
REMain.SelLength := Length('something');
REMain.SelAttributes.Style := [fsBold];
end;
But since I don't know any better, please criticize and suggest how I can do it better.
Is there a way to set a certain text like text1 on a Rave Report to a certain Edit.text on a Delphi form you print from in your Delphi application.
I want to create an application form in a delphi application where each block represents a certain letter of a word... for example - Edit1.text := Surname
On my Rave Report text1 should show Edit1.text[1] (S), text2 should show Edit1.text[2] (u) ... and so forth. I know how to use the datatext function in Rave Report... but that would mean I have to save each letter of each field in a database column separately first... :(
Please help me if you can... coz I'm very stupid when it comes to this sort of thing.
Since this looks quite strange for me and I would strongly consider to set your TEdit.Text directly from your application not from the report and since it's not quite clear what you are asking here I'll try to show you how to get or set the text from or to the Text component in Rave Reports.
Let's pretend you have the Report1 with Page1 where the text component named Text1 is placed somewhere. All of this is by Rave Reports designer saved in the C:\YourRaveProject.rav file. Then assume you have in your Delphi project a button with the following code in its OnClick event handler and two edit boxes, Edit1, where we load the text from our Text1 component and Edit2 from which we set our Text1 component text.
uses
RpRave, RpDefine, RpBase, RpSystem, RvCsStd;
procedure TForm1.Button1Click(Sender: TObject);
var
RaveProject: TRvProject;
begin
RaveProject := TRvProject.Create(nil);
RaveProject.ProjectFile := 'C:\YourRaveProject.rav';
try
RaveProject.Open;
RaveProject.SelectReport('Report1', False);
// get the text from the Text1 component from the report
Edit1.Text := (RaveProject.ProjMan.FindRaveComponent('Page1.Text1', nil) as TRaveText).Text;
// set the text of the Text1 component on the report
(RaveProject.ProjMan.FindRaveComponent('Page1.Text1', nil) as TRaveText).Text := Edit2.Text;
// and execute the report for showing the result of setting the text
// note, this can be omitted of course if you want only to get the value
RaveProject.ExecuteReport('Report1');
RaveProject.Close;
finally
RaveProject.Free;
end;
end;
Please, take this as an example, not as a real answer to your question because IMHO it's unanswerable at this time. If you specify the exact question then we might be able to help you with your real problem.
Tested on Delphi 2009 with Rave Reports 7.6.2.
We are upgrading our application for rich text editing. In the old versions there were just plain text with dbmemo, now there should be some formatting and I want to use the TJvRichEdit for this.
The problem: The texts that already exists in the database is plaintext.
When I open a mask and don't change anything in the richEdit, its still plaintext without the rtf formatting tags.
What I need: the old plain text should be automatically converted to rtf text after displaying. (I mean, I open a mask with a richEdit which displays plaintext, and at this moment the plaintext should be enhanced with the rtf tags and saved to the databse).
For this purpose I've created a descendant of the TDBRichEdit.
But I have problems to finda propper place to make this happebs.
For now, I've overwritten the setBounds method with the following code:
procedure TMyRichEdit.SetBounds(ALeft, ATop, AWidth, AHeight: Integer);
begin
inherited;
...
if (assigned(DataSource)) AND (assigned(DataSource.DataSet)) AND
(self.Text <> '') AND
(LeftStr(sDataSource.DataSet.FieldByName(DataField).AsString, 5) <> '{\rtf') then
begin
self.DataSource.DataSet.Edit;
// After a call to UpdateMemo the plaintext gets extended with the rtf tags
self.UpdateMemo;
self.DataSource.DataSet.Post;
self.DataSource.DataSet.Edit;
end;
...
end;
So this works, but only if the richEdit has an anchor set. If not it doesn't work.
I know thats the wrong place for this code, I've tried overwrite more propper methods but without access.
How can I solve something like this?
Thanks guys!
You don't need to derive a new class, you can test and process the field contents in the OnAfterScroll event of the DataSet;
procedure TForm1.MyDataSet1AfterScroll(DataSet: TDataSet);
begin
if LeftStr(DataSet.FieldByName('MyRTF').AsString, 5) <> '{\rtf') then begin
DataSet.Edit;
JvDBRichEdit1.UpdateMemo;
DataSet.Post;
end;
end;
Honestly, I don't even see the need for updating each record as soon as they're exposed. I would leave them alone until they're edited, test for the the rtf signature and update them just before posted.
Otherwise, if you'd insist on your approach, and if you decide to use TJvDBRichEdit, LoadMemo would be a good place to override. But editing there would probably cause recursion, so a user message could be posted to the owner form for notifying edit contents have been loaded. Nah, not good.. ;)
I need to copy a form (Delphi 2007) to the clipboard as an image to paste what the user can see into a word document. The clipboard part is not really a problem. The questions is how to get a bitmap for the form.
Searching has turned up multiple options.
Call GetFormImage
Use the PrintWindow API function that is part of the GDI+
Send a WM_PRINT message
Copy the Canvas for the current form using Canvas.CopyRect
I also found a component called TExcellentFormPrinter that has a solution that claims to works better than any of these options, but I don't know what method it is using.
All of these options seem to have different problems. Most of the information I am finding seems to be outdated. I can't seem any good source that compares the different options with enough detail for me to make a choice. Any advice on which option to go with.
I have tried these on my form and they all seem to work OK, I just trying to avoid problems down the road. Any advice on what solution to go with?
Update: What Potential Problems with GetFormImage?
Andreas asked what the problem is with GetFormImage. Hopefully nothing anymore, that is part of what I am trying to get an answer to. What has me concerned is so many of my search results seem to be suggesting creative alternatives to using GetFormImage. I was hoping the answers would clear up the waters a little bit.
I would be really happy with an answer that got a lot of up votes that said - GetFormImage used to have some problems but there is no reason not to use it now. :-)
As to the actual problem with GetFormImage. One issue for some users was only the visible part of the form would appear in the image (i.e. you can't capture a hidden or overlapped window). That is not really an issue for me as my entire form is visible.
1) The bigger issues deal with specific support required from the controls on your form. The Delphi 4 Fixes and Known issues page list has this entry (note it is listed as "Deferred to Next"). I could not find a QC entry that showed this resolved:
Area: vcl\core vcl classes
Reference Number: 1088 (Published: 12/16/98)
Status: Deferred to Next
Rel Date Reported: 8/6/98 Severity:
Commonly Encountered Type: Basic
Functionality Failure Problem:
The problem is with GetFormImage most nest windows controls like comboboxes, etc. are drawn blank.
2) I am also using the DevExpress controls. At one time their controls (fixed at the end of 2006) did not support the PaintTo messages that GetFormImage was using. This is fixed in the DevExpress release I am using, but it raises other issues with me, what is the chance that other control I am using may not work correctly?
3) Here is a more recent (2010) post on the Embarcadero Groups. The user was having trouble using GetFormImage where part of the graph they were showing on screen did not appear in the final image. They also needed the form caption included (which I do not) and they took the Canvas.CopyRect approach outlined in this post.
4) Here is the quote from the TExcellentImagePrinter page. I would have no problem buying their product if needed. There component looks like it was last updated in 2002 (There is a Delphi 2007 trial version though). I can't tell if I really need to go that direction or not.
You can try using GetFormImage or
Form.Print. Try dropping a ComboBox
down on a form, then call GetFormImage
or Form.Print. If you get a
printout, do you see the text in the
ComboBox? No? Neither does anyone
else! This is only a small example of
the problems you will encounter when
printing VCL forms.
You can also try using Borland's
TI-3155 "A better way to print a
form". I wrote the TI when I worked at
Borland as a stop gap measure. While
it will print the combobox text, it
will fail on many printers, it can't
print the entire form if your user has
resized the form, and it can't print
forms that are hidden from view or is
located partially off the screen. The
code basically produces a screenshot,
and to print an image reliably, you
would probably want to take a look at
our TExcellentImagePrinter product!
Why? Simply put, it can require a
couple of thousand lines of low level
graphics code to get bitmaps to print
well under Windows.
I do not know what the problem is with GetFormImage, but an option that you have not tried (at least not explicitly) is
procedure TForm1.FormClick(Sender: TObject);
var
bm: TBitmap;
begin
bm := TBitmap.Create;
try
bm.SetSize(ClientWidth, ClientHeight);
BitBlt(bm.Canvas.Handle, 0, 0, ClientWidth, ClientHeight, Canvas.Handle, 0, 0, SRCCOPY);
Clipboard.Assign(bm);
finally
bm.Free;
end;
end;
In almost all cases I would expect this to produce the same result as
bm := GetFormImage;
try
Clipboard.Assign(bm);
finally
bm.Free;
end;
though. (Also, the Canvas.CopyRect procedure employes StretchBlt which I would expect to produce the same result as BitBlt when no stretching is applied.)
Method 2
You can always use Print Screen:
procedure TForm1.FormClick(Sender: TObject);
begin
keybd_event(VK_SNAPSHOT, 1, 0, 0);
end;
This will also capture the border and the title bar. If you only wish to obtain the client area, you can crop the image:
procedure TForm1.FormClick(Sender: TObject);
var
bm, bm2: TBitmap;
DX, DY: integer;
begin
Clipboard.Clear;
keybd_event(VK_SNAPSHOT, 1, 0, 0);
repeat
Application.ProcessMessages;
until Clipboard.HasFormat(CF_BITMAP);
bm := TBitmap.Create;
try
bm.Assign(Clipboard);
bm2 := TBitmap.Create;
try
bm2.SetSize(ClientWidth, ClientHeight);
DX := (Width - ClientWidth) div 2;
DY := GetSystemMetrics(SM_CYCAPTION) + GetSystemMetrics(SM_CYSIZEFRAME );
BitBlt(bm2.Canvas.Handle, 0, 0, ClientWidth, ClientHeight, bm.Canvas.Handle, DX, DY, SRCCOPY);
Clipboard.Assign(bm2);
finally
bm2.Free;
end;
finally
bm.Free;
end;
end;