Breakpoint Llc
Rocki Eibl
I came across this old topic while searching for a possibility to get the current breakpoint or view size information. I encountered multiple situations where I missed this information. Unfortunately the viewport size made available in recent releases does only provide very limited possibilities.
Imagine a flex repeater or container with child views which have a variable height. E.g. on smaller screens they align their elements vertically, on bigger screens horizontally. The container / repeater is set to column so that the child views are stacked vertically.
To make that setup scale properly we need to set a minimum height for the elements in the repeater (basis property).
This size is variable and depends on the currently active break point of the child views (and therefore indirectly on the size of the repeater itself). None of this information is available.
The viewport which has been exposed in current versions is not useful in this case, because the repeater / container size is different from the global viewport size.
As stated above, the reason for not exposing the breakpoints is because it can be misused to create infinite loops.
I do not really see this as an argument, since there are many other ways for a programmers to create infinite loops if they are not aware of what they are doing. But it would not even be necessary to actively influence the breakpoints (which does not make sense).
Only having read access to this information would already be extremely beneficial to resolve a lot of challenges which are barely solvable right now. Knowing the current size of a view / component would also solve the problem.
13351193 46 KB
I have to make the flex views (they are also using column containers) higher to accomodate my phone but on my PC and tablet it shows white lines, having the actual current viewport width would allow me to dynamize the flexviews height
Maybe you can get the column container to work for you, but I gave up on it a long time ago, in part due to this reason and due to it being so hard to configure and move components around intuitively.
After a 5min play, what about using a flex with wrap set? not sure if there's a better way, but in the template on the text group and the buttons group I set the heights manually so that I could use an auto basis in when I embedded them into a flex container to allow them to shrink and expand when the width forces them to wrap...
Edit: I added the gap property to all the flexes, I didn't redo the screencapture though...
This is what gap does, it adds fixed gaps between components in a flex:
So it doesn't look like this:
I have to agree that 1024px would be a much better breakpoint than 991px. It just feels safer to have a slightly larger breakpoint imo. If not that, then at least a way to change the breakpoints in Settings. Having to write custom css media queries everytime is a pain.
I'm working on several apps that were developed on Xcode 12.5. Using Xcode 13.1, I set a breakpoint, which correctly appears as the blue marker in the left-hand column of the editor. When I run the apps (in a simulator), the breakpoint turns to an outline of a breakpoint marker, with a dotted blue outline and a white interior. The apps do not stop at the breakpoint.
I just saw this happening too, then I realized that the code wasn't being called. Meaning once the app compiled and the compiler realized it was not possible for the breakpoint to ever hit it would turn to the dotted outline. At least that was the case for me.
I'm the original poster on this question. I wish I could give you an answer, but I cannot. The situation I originally described corrected itself; I can't tell you what was wrong or what fixed it. I have seen the same behavior a couple times since, but again, it seemed to resolve itself. Apple tech support was of no help.I wish you luck in finding a solution and please post it if you find one.
I was stuck with this issue for a year - I had scoured the forums and the rest of the internet for any clues and just recently finally was able to get past this issue. The solution for me was to simply reclone my repository in a new directory. Once I created a new local repo at a different path the debugger magically worked again! I hope this helps someone in the future!
When I hit Debug. System stops at first line of main() as intended. However no matter how I setup any breakpoints on the rest code, and hit Resume(F8) button. The code never stops on those breakpoint. even though I am 100% sure those breakpointed line code got run already. and if I hit suspend. the code stops normally. Also step into or over works normally. ( I am sure that the number of breakpoints I setup is less than 4) I checked log file of st link GDB server. I did not see any breakpoint setting command sent to the debugger via the SWD. Is this a software bug of CubeIDE? I saw some youtube video. it shows the breakpoint works fine. Could anyone give me some hint. I stuck on this issue for two days. :(
When I set a breakpoint in my class library project. It appears as a normal breakpoint. When I start debugging my solution the breakpoint becomes hollowed out and has a yellow triangle with an exclamation point inside. The tooltip displayed when I pan over the breakpoint is, "The Breakpoint will not currently be hit. No Symbols have been loaded for this document."
I have taken over an existing winForms application with multiple projects in the solution. I have the project built and running in debug mode. I can stop at breakpoints in some projects but, I am unable to hit the breakpoints in other projects specifically my project that is of type class library.
All of the posts I have read have been very informative, but none of the suggested solutions have fit my specific needs. Please let me know if more information is warranted. I have more links I can provide as references to what has not worked. As well as additional steps I have taken to attempt to solve this issue.
My project is an ASP.NET application, but the base problem will happen on WinForms as well. The problem arises when a DLL is missing from the assemblies output. However, this same exception occurs if the DLL you are referencing then references another DLL that is not in the assemblies. Due to the way the operating system loads DLLs, the referenced DLL must be in the environment path, and not in your output assemblies.
The core cause to this problem is in the way the operating system loads native DLL's at >runtime. Native DLL's are loaded using the following logic which does not include the >Temporary ASP.net Files nor the applications /bin folder. This problem will also occur in >any .Net application if the Native DLL is not included in the /bin folder with the .EXE >file or if the DLL is not in the Path Environment Variable.
I was using a DLL called DivaAPIWrapper.dll (Managed DLL for C#). I knew, however, that DivaAPIWrapper.dll needed DivaAPI.dll (Unmanaged C++) to operate. I placed DivaAPI.dll in all my output paths but I kept receiving this error. Only after I placed DivaAPI.dll in my environment path (C:\windows\Microsoft.Net\Framework\v2.0.50727) did it work. Please note: your path may be different if you're using a newer version of the .NET framework!
I have this happen all the time, like you said the breakpoint is not active until the DLL is loaded. It really doesn't matter though, because it has to load the DLL before the code can get to that point anyway. My breakpoints start this way but they always get hit.
Check that you didn't change the processor at which you aimed to compile this project. I had, and when I changed it back, everything worked again. Apparently a change in processor makes it 'different than the original'
I had the same Problem with VS2008 in a Vb.net-forms application where I called a dll in another project, loaded in the same project group. I found this simple solution: I loaded an instance in the form_load event like Dim pmg As New PMGExport.PMGExportNeu.
I'm using CC2650 rather than Tiva, but I think I've seen CCS* use up multiple AET resources for a single breakpoint placed in source code. I get the same warning as Keyur, but the breakpoint list shows only one entry. When it happens I've been able to work around it by removing the breakpoint from the source code and placing it in the disassembly view instead.
Hi Ki, thanks for your reply, I got to learn about breakpoints better. but I tried to disable them, but could find a option as mentioned in your link.
Can you please tell me where I can find them for the configuration I mentioned in my post? Or can I replace them with software breakpoints, if possible?
Ki-Soo Lee said:Depending on the type of breakpoint, more AET resources may be used. For example, a HW breakpoint that halts the target when reached should use just one resource. But if the breakpoint has a different action or trigger (like halt on specific condition (besides when address reached) or do not halt when reached but do action "X"), more resources can be used.
...unless you want to embed the software breakpoints in your code at build time, which means they're always present and can't be disabled at debug time. Sometimes that's useful, for example in the fault trap and default ISRs you can break into the debugger rather than just looping forever.
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
I just made some variables in Xcode an I got this "Thread 1: breakpoint 1.1" highlighted in green when I tried to run the code. Can somebody tell me why this happened and what I can do to fix it. Thanks!
c80f0f1006