How could the C++ Builder XE debugger be affecting my code? - c++builder-xe

Using C++ builder XE
I'm using a TStatusBar on a form with 2 panels. The first panel is just text. The second is set to OwnerDraw and should indicate a red or green panel showing if a comport is connected or not. This is updated from a TTimer on a form with an interval of 500ms.
What seems to happen is that when I run the program from within the IDE (with the debugger), it works OK, but when I run it from the .exe file in the destination folder, of from within the IDE without the debugger, it doesn't update the status bar.
This is really annoying, because as soon as I run it under the debugger to debug it, it doesn't go wrong !
It seems that the OnDrawPanel event handler is not getting called when I'm not using the debugger.
Anyone got any ideas why, or a way round this ?

Related

VS Code debugger toolbar buttons disabled during debugging session

I am a beginner C programmer. Currently, I have Visual Studio version 1.61 September 2021 installed
on my windows 64-bit system. I also installed MingW64 and set up the environment variables to compile and debug with the purpose of writing, debugging and running my c programs.
I have been able to write and run my programs without any issues. I did notice that whenever I wish to debug my program, the debug toolbar that hovers on top has the buttons disabled and no line is pointed by the "yellow arrow".
I modified the "launch.json" file where I set the following:
"stopAtEntry": true,
This set the yellow arrow to point at the beginning of the program instead of the breakpoint and the debug toolbar buttons were activated. Though whenever I step-over on to the next line of code, the yellow arrow disappears and the debug toolbar buttons are deactivated once again.
This happens often on lines where I assign values to variables.
I am a beginner and I find VS Code quite frustrating, I would appreciate your input and suggestions. Thanks
UPDATE: I solved it.
So it turns out that there is nothing wrong with my debugger and it was behaving as it should. I noticed that it would always fall into that behavior whenever the gcc compiler was to execute the line including scanf(). The registers and variables in the watchlist would suddenly become "unavailable" this is because the compiler was waiting for user input.
Since VS Code did not show the running program on PowerShell, I modified the "launch.json" certain configurations to the following:
"externalConsole": true,
This allows for Command Prompt to open up, display the running program and allows for user input.
Once the user input is received the debug toolbar buttons are activated again and I could continue debugging. The watchlist variable also become available to analysis.
"stopAtEntry": false,
I set this configuration to false because I did not wish for the debugger to begin at the beginning of the program.
This was certainly frustrating but after finding the solution to this "issue", I bet that my endorphin and oxytocin levels are off the charts.
Very thrilling, this is what I love the most about problem solving.

VisualStudio2015 debug issue

i have a solution
it has 2 projects inside.
there are an exe and a website.
the issue occurred when clicking F5 to start the debug process.
when i have set the exe to the default StartUp project. The exe can run normally, and the break point can be reached correctly.
however, when i have set the website to the defualt StartUp project. The website can be launched, however the breakpoint cannot reach. also the version isn't the latest one, it looks like it is loading the last succeed version (no error and warning too)
I have to right click the website project and click start new instance in the Debug every time I have modified something!(which is very troublesome)
Thus, I want to know why my F5 isn't equal to the Start new instance, as it is working normally in the other solutions.
I fixed that but the below procedures after struggled from extra many clicks compiling experience.
the cause is that there is unknown reason that the build checkbox isn't checked in the configuration manager. simply check it and everything looks fine again...
hopefully it can save someone time who suffered from this issue in the future

UFT - Object Identification not working on Run Time

I have written a code for Web page. The process requires me to click on a weblink which opens up a new window, then perform some operations on the browser window. Then I close the new browser. This is repeated multiple times in the code. All the elements on all the browser windows are normally identifiable using the object spy. However, intermittently during run time when a new browser window opens up the elements on the page are not getting recognized (hence it throws errors). When i go into the debug mode and try using the object spy the maximum identification i can capture is Browser(<>).Page(<>). Nothing in the page is getting recognized.
Now if i close this browser and reopen it and check again, the elements on the page are getting captured by the object spy and i can continue with my script execution. Sometimes I have to close and reopen multiple times for it to work.
Is there any way to handle this scenario. check for object identifications on the run time maybe. Dunno if it this is any relevant but i am not making use of the OR in my project.
Thanks in advance.
This sounds like a bug in UFT and you should contact HP's support.
A workaround if you know where the problem is probable to appear is to add Browser("<name>").RefreshWebSupport. This is an undocumented feature of UFT that sometimes helps in cases like this.

Debug problem occurs sometimes in Silverlight when in Chrome

I am using a dedicated test SL web application that hosts SL object I am debugging.
I am debugging using basic F5 and use browser Google Chrome. Sometimes a bug happens, how I reproduce it.
I was running build->debug like 100 times already, but then I made a mistake that caused StackOverflowException and happened in main page constructor and afterwards when I rebuild and hit F5 it says no symbols have been loaded. Note that NOTHING has changed , I use the same 2 buttons combinations rebuild solution-> start debugging.
In order for debug to continue to attach I need to close XAML main page , open it again (in visual stuido) and hit rebuild ->f5 again, afterwards it works fine. (found this solution after SOME time)
I am not sure whats bugged but it appears to be a bug somewhere in SL to me.
Question is - whats going on maybe someone can explain.
This sounds more like Chrome's isolation mode for plug-ins. Generally speaking it's best to manually attach to the Chrome process that is running Silverlight (which isn't always one VS attaches to when pressing F5).
Actually error was super simple, I wasn't understanding how "exactly" xap works, it was a little more magical to me than it is. I just needed to rebuild & clear cache in browser ( chrome in this case) to attach successfully. For some reason I thought that local version doesn't require clear cache call.
Actually chrome is pretty bad to debug silverlight so I recommend IE for this sole purpose, sometimes debugger simply fails to attach to chrome, in that case you usually need to do this by attach to process - choose chrome with silverlight name there.

Another knack on the "Dialogs must be user-initiated" Security Exception in Silverlight printing

I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.

Resources