RemedyBG

Hi there.

First a bit of an introduction as I am new to the community. I have been a jack-of-all-trades developer for several years. I have been lucky to get a broad experience, but always with managed languages. In my field there's rarely a business justification 🤮 to go deep.
I have been working my way through Handmade Hero. It's helping me understand things at a deeper level and rekindling a love of programming. Casey is an amazing teacher.

Here is my question: what causes the debugger to be unable to set a breakpoint as in the picture below? The issue disappeared after I went back to older git commits and then back to my latest state. Visual Studio was still able to set a breakpoint.

Hello!

I had the same problem and the solution in my case was to turn off incremental linking and to make sure that the project is completely rebuilt (this may also be the reason that it worked for you after a revert / clean).

Be sure to add something like "/INCREMENTAL:NO" to your linker options and clean and rebuild the project. remedybg really hates incrementally linked executables and unfortunately does not give you an error message if you have one, it seems.

Even after adding /INCREMENTAL:NO I sometimes had to clean and rebuild to get good debug functionality. I'm not sure whether some incremental stuff is "sneaked in" by the Microsoft tools or not.

best regards

Edwin

Thank you Edwin, I'll be sure to try this.

I'm not able to hit a breakpoint on a basic Visual Studio 2019 project either. I turned off incremental link and rebuilt but that didn't change anything.

Do you have /Z7 ir /Zi debug information format? /Zl may not work well.
And have you disabled /DEBUG:FASTLINK? Use /DEBUG or /DEBUG:FULL in linker settings

Changing from /DEBUG to /DEBUG:FULL fixed my issue. No other setting seemed to matter. I'm rather surprised /DEBUG doesn't work.

Thanks for the quick assist!

Hi, thanks for the extra information.

I'm now using /Zi on the compiler and /INCREMENTAL:NO /DEBUG:FULL on the linker and I *still* sometimes get the problem described by the OP. The one thing that consistently helps is cleaning the project and rebuilding. I'd really like to understand what is going on and whether I am missing any necessary settings.

If you get into a case where that happens again I'll be happy to take a look at the corresponding PDB.

I've seen cases where the PDB keeps around old type information from previous builds. For instance, if you change a data structure (say add or remove a field) then both variants can be part of the type records in the PDB. I'm guessing this was a necessary optimization at some point in the distant past. The policy I'm using for these type records is that the last type record with a given name "wins". Either this logic is broken or I'm making a wrong assumption about these unused type records (or not reading some additional info elsewhere). In any case, I'll need to get this corrected on my end.

--
George

OK, thanks. I'll save working/non-working .exe and .pdb when this happens again. Is that sufficient or do you need source, objects, too in order to debug?

Just the PDBs are enough. Thanks!

Hi George,

strangely enough I did not encounter the problem again since we exchanged these messages. Maybe all the incremental stuff is finally flushed out of my project.

I did notice another intermittent problem where remedybg sometimes does not react to F5. I do not know yet how to reproduce it as it seems to happen randomly from one keystroke to the next. I'll report something as soon as I can reproduce it reliably in one case.

BTW, thanks for the recent updates to remedybg! I'm finding that the removal of the tab-closing Xs alone is already a big improvement and makes remedybg much more comfortable to use. (I think the addition of those Xs was a historical/cultural mistake probably introduced by web browsers. It is not as bad in web browsers, though, as they usually have the tabs at the very top of the screen and one can "slide" the pointer along the top edge of the screen when changing tabs and thereby avoid clicking the X unintentionally. Also with web browsers, closing tabs is quite frequent, so it's a better trade-off in this case.)

best regards

Edwin

edwinst

BTW, thanks for the recent updates to remedybg! I'm finding that the removal of the tab-closing Xs alone is already a big improvement and makes remedybg much more comfortable to use. (I think the addition of those Xs was a historical/cultural mistake probably introduced by web browsers. It is not as bad in web browsers, though, as they usually have the tabs at the very top of the screen and one can "slide" the pointer along the top edge of the screen when changing tabs and thereby avoid clicking the X unintentionally. Also with web browsers, closing tabs is quite frequent, so it's a better trade-off in this case.)

I don't agree with that. I prefer the x in the tab as it makes more sense to me. It makes it directly obvious to me that it will close the selected tab. The x in to top right corner to me means "close the whole view/all the tabs". It's probably a perception thing, but I'm not sure that most people prefer it the way it is now.

A detail for @x13pixels: if you keep it without the x in the tab, there is now an empty space next to tab titles that is wasted space.

mrmixer

I don't agree with that. I prefer the x in the tab as it makes more sense to me. It makes it directly obvious to me that it will close the selected tab. The x in to top right corner to me means "close the whole view/all the tabs". It's probably a perception thing, but I'm not sure that most people prefer it the way it is now.

A detail for @x13pixels: if you keep it without the x in the tab, there is now an empty space next to tab titles that is wasted space.

For any such detail there will be opinions on both sides. It's surely difficult for an application developer to get an idea which fraction of users prefers any single choice. Making everything a customizable option, on the other hand, increases complexity a lot. I'm certainly not alone in finding the X's bad, as I found that there was already a github issue filed on this topic. For the record: I also don't like the X in the right corner. For me, closing views is such a rare occurrence in debugging that I'd be fine with spending no screen real estate at all on closing views.

If I try to quantify it, I think for my use, the ratio of switching tabs to closing tabs in the debugger is at least 10:1 and probably approaches 100:1. There may be whole extended debugging sessions in which I don't close a single tab but switch many times. With the Xs I feel a bit like training kung fu on poles ;-).

P.S.: I think I have a second argument to defend that the Xs are objectively bad user-interface design, in addition to the point that it is a bad trade-off to use ~20% of screen area of an UI element for clicks that happen <10% and maybe less than a couple percent of the time and have a relatively high "annoyance cost" when they are made inadvertently: If you switch tabs going from right to left, the X is actually in the first area of the new tab that you reach. That means that its "effective area" (which quantifies how large of an obstacle it presents) is actually even bigger than its pixel share in the tab. It is precisely where you would prefer to click when you switch to a tab that is to the left of your initial pointer position.

edwinst
P.S.: I think I have a second argument to defend that the Xs are objectively bad user-interface design, in addition to the point that it is a bad trade-off to use ~20% of screen area of an UI element for clicks that happen <10% and maybe less than a couple percent of the time and have a relatively high "annoyance cost" when they are made inadvertently: If you switch tabs going from right to left, the X is actually in the first area of the new tab that you reach. That means that its "effective area" (which quantifies how large of an obstacle it presents) is actually even bigger than its pixel share in the tab. It is precisely where you would prefer to click when you switch to a tab that is to the left of your initial pointer position.

I wouldn't call that "objective" as there are no measured metrics provided.

Again I don't care much about that issue, but I have a very different experience than you have.

I barely never manually change tabs in the file view, as they change automatically when I step. When I read code, I often use the call stack to go the previous functions. Most of the time (I think, I haven't measured) when I manually change tabs, it's to place a breakpoint (and it's not each time I place breakpoints as I can use "add function breakpoint", or be in the correct file already as it most likely related to the current debug state). And my annoyance there is more finding the correct file, as I found tabs and drop down list not well suited for that (I would like to try something similar to 4coder listers to see if it's better).

I close file tabs often actually to keep the number of tabs small and make it easier to find the file I want. And I can't remember the last time I miss clicked the x. It probably has happened but not in a long time for me. I don't know about the "effective area" of the X when coming from a direction... I just click around the center of the tab as I would expect most people to do (again I haven't measured).

mrmixer
Again I don't care much about that issue

Actually, now it takes two clicks to close a tabs because I need to select it before closing it. And then go back to the tab I want if it wasn't the next one in the list. So I kind of care :-)