Conference pamsrc::objectbroker

	I'm not sure what you are saying.  There is a known problem
	(and an outstanding QAR) that most of the includes files
	and some other files on all the Windows platforms (NT,
	Win95, and Win3.1) have all lines only terminated with
	a newline character (ala control-J), and not a carriage
	return newline pair, and that the NOTEPAD application
	doesn't handle carriage return-less text files.

	Is this what you are saying?  If so, the answer is that
	the reason the files are like that in the 1st place is
	a side effect of the source control system and the processes
	used to get the sources to the build systems.  The reason
	some files (like the online release notes) have the Windows
	standard line termination is because the existing kit creation
	process specifically changes the line termination for a
	select few ascii files.  It would be not be practical given the
	existing tools (ie. it doesn't scale well) to do it for all
	the ascii files that are shipped.  Early last year I did
	design and prototype a new tool that would create the NT
	kits with one of it's features being that it would make sure
	all ascii files placed on the kit have the correct line
	termination for Windows.  That new tool however is not
	yet in use.

    Jeff,
    
    Thank's for having a look on it. In fact your reply tells me that
    ObjectBroker Engineering is very aware of the situation but does not
    have it under control. Unfortunately since quite some time the
    situation did not change on this front.
    
    Imagin you buy a a newcomer customer a product for 2500 buks for NT and
    then you take the NOTEPAD editor in atempt to view few exampe files
    like .IDL, Makefiles, all the example code. If your lucky you will see
    nicely formatted files. But if your unlucky all you see are tons of
    unreadable wrapped rendered files due to this CTRL/J type wrapping.
    
    No good first impression; i.e. notepad obbquick.cxx, notepad
    obbquick.c, notepad any.cxx, notepad boa.cxx .... and so on for all the
    ./include files,
    
    OK: the negative effect is seen with CTRL/J and NOTEPAD or SEDT
    using EDIT is OK even the file has CTRL/J's in it.
    
    Workarround: I send the file using CuteFTP in ASCII mode to a UNIX
    machine and then back in ASCII mode, overwriting the existing file and
    all the CTRL/J's are gone. Then I have what I want, SEDT, NOTEPAD and
    EDIT all show well formatted files.
    
    I understand your claim for a common source code system; this is a
    very leagl technical issue, a must. 
    
    But I hope you understand the sales point as well, the impression a
    customer has up on this product when he just bougth his kit for 2500 buks
    and then sees badly formatted files.
    
    The solution is what your aiming at but did not reach so far.  Please
    fix it (remove this CTRL/J's by CR/LF) before you kit it. 
    
    Sepp;

Wordpad has no problem with the files. In addition it copes
with much bigger files. I always associate IDL/IML/MML/COL
with Wordpad these days.

Wishlist: add an edit association to the right-button click
of ObjectBroker files which points to Wordpad.

John D.

    John
    
    That is the solution for the damed CTRL/J problem.I just wonder why I
    (speaking also for customers) have to setup this myself if I pay for an
    NT developers kit some 2'500 buks.
    
    Sepp

> There is a known problem
> (and an outstanding QAR) that most of the includes files
> and some other files on all the Windows platforms (NT,
> Win95, and Win3.1) have all lines only terminated with
> a newline character (ala control-J), and not a carriage
> return newline pair, ....

	For reference, since I was just asked, the outstanding QAR
	numbers are 2848 and 2465.  I don't know if they got transfered
	to the PTR system or not.

    This is PTR 16-3-248