Page 1 of 1

Compiler debugging/command prompts inhibited by Richview

Posted: Fri Nov 14, 2014 2:04 am
by pbarrettx1
This is an awkward one - I'm sure I must be missing some kind of environment command or something .. but, since using Richview circa 2007 and onwards with Delphi (now just upgraded to XE7), I'm still experiencing the same issues when using Richview:

1. When making coding errors in a VCL Forms application module, the line numbers of the errors don't match the actual error occurence. This only happens with a module in which Richview code is embedded. For example, I make a deliberate error in line 381 of a module (writing table34.Cells instead of table1.Cells); the compiler reports the error occurring at line 307 instead of line 381:

[dcc32 Error] Unit2_Effect.pas(307): E2003 Undeclared identifier: 'table34'
[dcc32 Error] Unit2_Effect.pas(308): E2003 Undeclared identifier: 'Clear'
[dcc32 Error] Unit2_Effect.pas(308): E2003 Undeclared identifier: 'AddNL'
[dcc32 Fatal Error] F2063 Could not compile used unit 'Unit2_Effect.pas'


2. When looking for the drop-down command listing for either standard Delphi or Richview commands (e.g. following the use of a full-stop after a compenent reference such as Edit1. , nothing happens - no drop-down listbox). It seems to be Richview Table-command specific (in that when using the Table commands this seems to happen after them - but I have a feeling it is not as consistent)).


Otherwise, everything works fine with the Richview component.. compilation, functionality, and implementation of Richview code. It's just a bit inconvenient on occasion when trying to debug code and having to figure out which line actually contains the error which will always be near the line given for the error.

It's really weird! I'm happy to send a video of the issues and the entire project code; but I was just wondering whether anyone else had experienced this, and if so, what is it I need to be doing to have the Richview componentry behaving as any other Delphi component, 3rd party or otherwise.

My "uses" clause in the unit using Richview is:
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, RVOfficeCnv, PtblRV, RVStyle, RVScroll, RichView, RVTable, StdCtrls,
LMDCustomButton, LMDButton, Printers, gtClasses3, gtXportIntf,
gtRichViewIntf, RVReport, gtCstDocEng, gtCstPlnEng, gtCstPDFEng, gtExPDFEng,
gtPDFEng, RVEdit, Vcl.ExtDlgs, jpeg;

And although I'm using edocengine modules (they begin with gt), this happens without using any edocengine component.

I use LMDTools, LMDElpack, TMS Component Pack, Steema Graphics Pro, TMS Flexcel, TMS Industrial workbench, and edocengine .. and none have produced the same problems. So, either I'm not installing correctly, not pathing correctly, or missing an environment variable or something else altogether (I've set up the usual browsing/dcu, and library search paths as per normal (referenced to where the application files reside, as well as where the .bpl files reside).

As I say, I've worked with this weird behaviour since 2007 and every version of Richview and Delphi in-between. I reckon it's time I asked for help to fix this problem as it may be extremely simple!

Thanks .. Paul

Posted: Fri Nov 14, 2014 8:44 am
by Sergey Tkachenko
Please check, may be you have a unit with the same name somewhere.
I had such problems several times - Delphi shows one unit in IDE, but displays errors for another one.

Compiler debugging/command prompts & Richview

Posted: Fri Nov 14, 2014 7:02 pm
by pbarrettx1
Thanks Sergey

Do you mean a unit in the program (i.e. I'm using 4 forms - but all with different names)

or

'unit' refers to anything in a "Uses" clause within the "interface" paragraph?

Thanks .. Paul

Posted: Sat Nov 15, 2014 8:04 am
by Sergey Tkachenko
I mean files - search for files having the same names in different directories, both pas and dcu.

Compiler debugging/command prompts & Richview

Posted: Sun Nov 16, 2014 5:24 am
by pbarrettx1
Ah, OK .. thanks Sergey .. I'll take a look .. nice to know what's causing the pronlem - even if it will be a pain looking for same-name files!