Unable to print

[Fabrizio The Cat 1]

Hi all,

 

after serveral days of tests, i am unable to print with cpp builder 12 CE.

the simple code:

 

void __fastcall TMain::BitBtn1Click(TObject *Sender)
{
Printer()->PrinterIndex = 0;  // here i select the default printer: a laser printer but the result is the same for all printer on my pc

Printer()->BeginDoc();        // here an excetion is raised informing that the selected printer is invalid. 

}

 

(the link  https://stackoverflow.com/questions/67233197/cbuilder-printing-issues-on-certain-printers?noredirect=1#comment120336791_67233197 is not working)

 

Why i can't print??

Thank you for the patience and the help.

Fabrizio

[Fabrizio The Cat 1]

Hi,

i have tried the simple executable above outside the debugger and it works with no error.

Then debugging the real program the problem appeared again, seems the 2nd time running it with errors in the subsequent code.

Launched the simple exe, no error. 

Then i was able to debug the code and correct it. Now with a correct source code after the line mentioned, subsequent runs of the program don't have problems.

Now i'm unable to reproduce this beaviour.

Seems that an erroneous code with exceptions raised (during debugging only?) can corrupt something (surely memory locations) and a subsequent call of a program outside the debugger can solve the situation. 

This seems to be a debugger problem that can't safely recover returning from a bad code: a simple program not in debug can execute the BeginDoc() and exit leaving the machine in good conditions.

 

What do you think about?

 

Thank you, Fabrizio

[Roger Cigol 139]

In my experience such "hard to explain" behaviour is usually the result of poor coding elsewhere that is corrupting something else (in your specific case most likely changing something associated with Printer()). Running under the debugger can change memory layout and hence change which bits the poor coding elsewhere is corrupting. The result is very hard to debug! But never impossible. Single step through and keep an eye on the values of all values used by your code watching for something that changes unexpectedly is one approach. Another is to isolate code and confirm that it operates correctly (or otherwise) in isolation. If you are going to adopt this approach then why not add each isolation test that you do as a unit test? Unit testing is a great way of significantly reducing these "very tricky to debug" bugs.

[Fabrizio The Cat 1]

7 hours ago, Roger Cigol said:

In my experience such "hard to explain" behaviour is usually the result of poor coding elsewhere that is corrupting something else (in your specific case most likely changing something associated with Printer()). Running under the debugger can change memory layout and hence change which bits the poor coding elsewhere is corrupting. The result is very hard to debug! But never impossible. Single step through and keep an eye on the values of all values used by your code watching for something that changes unexpectedly is one approach. Another is to isolate code and confirm that it operates correctly (or otherwise) in isolation. If you are going to adopt this approach then why not add each isolation test that you do as a unit test? Unit testing is a great way of significantly reducing these "very tricky to debug" bugs.

Hi Roger,

yes a poor code can result in this behaviour.  I have lots of test in my code and all are green.

My doubt is that the 2 code lines has the same problem as the large one and it appears when in debug mode only, never running it outside the IDE and the debugger.

 

Many thanks for the answer.

[Roger Cigol 139]

I am assuming this is a VCL app - is it 32 bit or 64 bit ? if 32 bit which compiler ? Which version of RAD Studio / C++ Builder are you using ?

[Fabrizio The Cat 1]

17 hours ago, Roger Cigol said:

I am assuming this is a VCL app - is it 32 bit or 64 bit ? if 32 bit which compiler ? Which version of RAD Studio / C++ Builder are you using ?

VCL app 32bit clang compiler Cpp builder 12.1 CE - Win 10 - 12g ram - i5 4440

 

thank you

[Roger Cigol 139]

@Fabrizio The Cat I am not sure if I can help you further. I am on RAD Studio 12.3 (about to change to 13...). I also have not used the clang32 compiler much. I have lots of still active projects based on the "classic" compiler and many that I've upgraded (and some written more recently) which are 64bit apps (and which will therefore benefit greatly from the step to RAD Studio 13).

If you are sure it's just the debugger then maybe you need to try moving to 12.3. I must admit I am still skeptical about this. Without much evidence to go on and certainly without wishing to cause offense I still suspect there is a problem in your code that shows itself in a different way under the debugger to the "release build".

[Fabrizio The Cat 1]

Hi Roger,

i can't move to 12.3 as i use the CE. The executable outside the IDE is the debugger version, simply launched  from the link on my desktop.

Yes, most likely is a poor code somewhere, but the 2 line code program works the same and this make me thinking..

 

Thank you very much for collaboration.