Im making a brick breaker like game and when I try to remove the brick, I remove the sprite, but not the collision. In new to HaxeFlixel so I don't have a clue why this is happening. Can somebody please help me? (code below)
The remove() function removes the object from the state, which is causing the odd behavior. You only want to disable the object.
Try changing the line remove(brick) to instead brick.kill() and see if that resolves your collision problem.
Related
So I've been trying to create a popup widget which should include 3 other widgets inside of it. I had to fix a bunch of things before I could get it to run without spitting out more errors. So I am at the point where I am trying to run it to see if it really is working. I made a button(day_button.lua) which will trigger the visibility of the container(empty-container.lua). So I typed at the top of rc.lua: local customclock = require("day_button") which like I said gave no output of any errors. I tried to place the button in my wibar like so: wibar(you can find it under the widget mytextclock). So by trying to "summon" the button I get these errors. I don't know what to do from this point forward. These errors aren't very helpful and I'm not that experienced.
I will also include day_button.lua and empty-container.lua for better context.
Please help.
The error message tells you that you're indexing a local boolean value v. You may only index table values.
So you're doing someting like v.someKey or v[somekey] or v:someKey in the mentioned line.
v is probably part of a generic for loop. So you probably have a boolean value in a table where you expect a table value.
you know what you're doing wrong and you know where. The only thing that's left is to fix it. So find out why there is a boolean where you expect a table. If it should be a boolean, don't index it. If it should be a table, make sure it actually is a table.
I have a program which loads multiple images and each image has an array of polygons which are represented by a custom QGraphicsPolygon item. I load 1 image at a time with its respective polygons into two QGraphicsScene (new QGraphicsScene on each load). The problem I am encountering is that after switching between image a couple times I get the following error:
"RuntimeError: wrapped C/C++ object of type ImagePolygon has been deleted". This implementation used to work well, but I have added a lot of stuff to the program since and now I get the error.
I know that I am never loosing my references to the custom QGraphicsPolygons and the only thing that is getting deleted inside them is the polygon itself. All other membervariables stay intact. Unfortunately I have not been able to pinpoint the exact region of the code where the polygon inside the QGraphicsPolygon gets deleted and the code is too long to post here.
I have also tried to simple set a new QPolygon to the QGraphicsPolygon item each time I add it to the scene, but this gives me the same error.
Please let me know if anybody knows what could be deleting this item. Keep in my I am never loosing reference to the QGraphicsPolygonItem.
I would also appreciate if somebody knew of a good way to debug this. I am sure I could fix the error if I could find it.
Thank you in advance
After a lot of testing I think I found the problem. Since in my implementation I delete the QGraphicsScene everytime I show a new image, I believe this was deleting the polygons as well. I don't know why this was not happening before, but I managed to fix it by first removing all items from the scene. I had to iterate through the items, because using the clear() method in the scene deletes them.
I have found a workaround for this, which I will be posting as an answer, but it still raises the question of why it happened in the first place.
When I try to add a new id through the Design GUI, I type the name into the box:
id_sample
As soon as I tab out of the box, it prepends #+id/:
#+id/id_sample
which sounds reasonable enough, because - hey, it's got to put in the instruction to add a new id per the documentation, right?
But when I go into the java code, autocomplete is giving me gibberish on the code side - because of the extra #+id/, autocomplete gives me #+id/id_sample for a grand total of
menu.findItem(R.id.#+id/id_sample);
which has invalid characters; while deleting them:
menu.findItem(R.id.id_sample);
gives the error Cannot resolve symbol 'id_sample' because the xml is insisting that the correct name includes the invalid characters. Catch 22.
So how do I properly reference an id?
Looking in the xml, the #+id/ actually gets added to the #+id/id_sample:
android:id=#+id/#+id/id_sample
which obviously gives the compiler a heart attack. Having figured out what was going on, it is easy (though tedious) enough to jump into the xml and delete the extra #+id/ but I can't see any way to get the designer to put it in right in the first place.
Once this is corrected in the xml, it gets automatically corrected in the GUI, autocomplete will give you the correct name when you go into the java code, and the compiler will recognize it.
All that's left is to wonder if there is something I'm doing wrong that is causing this. Is this a known (or unknown) bug? Knowing what is wrong, it can be fixed in the xml, but it seems the GUI should have gotten it right in the first place. Right?
Figured it out. LVIF_STATE should have been LVIF_IMAGE. See, I knew it was elementary...
I have a CListView derived class with an OnDoubleClick() handler in a VC++6.0 project. I need to persist the highlighting of the selected item after the OnDoubleClick() handler has done its thing. I had thought that
GetListCtrl().SetItemState(m_nHighlightIndex,LVIS_SELECTED, LVIF_STATE);
would do the trick (assuming that m_nHighlightIndex holds the index of the selected item), but no combination of that and various attempts to invalidate the client area has worked, in either OnDoubleClick() or OnUpdate(). This seems like such an elementary thing to do, but thus far it baffles me. Any help would be greatly appreciated.
Just so it looks answered (and apologies if this is bad form):
LVIF_STATE should have been LVIF_IMAGE. See, I knew it was elementary...
An obscure puzzle, but it's driving me absolutely nuts:
I'm creating a custom Information Management Policy in MOSS. I've implemented IPolicyFeature, and my policy feature happily registers itself by configuring a new SPItemEventReceiver. All new items in my library fire the events as they should, and it all works fine.
IPolicyFeature also has a method ProcessListItem, which is supposed to retroactively apply the policy to items that were already in the library (at least, it's supposed to do that for as long as it keeps returning true). Except it doesn't. It only applies the policy to the first item in the library, and I have absolutely no idea why.
It doesn't seem to be throwing an exception, and it really does return true from processing that first item, and I can't think what else to look at. Anyone?
Edit: Cory's answer, below, set me on the right track. Something else was indeed failing -- I didn't find out what, since my windbg-fu isn't what it should be, but I suspect it was something like "modifying a collection while it's being iterated over". My code was modifying the SPListItem that's passed into ProcessListItem, and then calling SystemUpdate on it; as soon as I changed the code so that it created its own variable (pointing at the exact same SPListItem) and used that, the problem went away...
There's only a couple of things I can think of to try. First, are you developing on the box where you might be able to use Visual Studio to debug? So just stepping through it.
Assuming that's not the case - what I'd do is fire up WinDBG and attach it to the process just before I registered the policy. Turn on first chance exceptions so that it breaks whenever they occur. you can do that by issuing the command "sxe clr" once it is broken in. Here's a little more info about WinDBG:
http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-crash-on-startup.aspx
What I'd do is then watch for First Chance exceptions to be thrown, and do a !PrintException to see what is going on. My guess is that there is an exception being thrown somewhere that is causing the app to stop processing the other items.
What does the logic look like for your ProcessListItem? Have you tried just doing a return true to make sure it works?
Some nice ideas there, thanks. The Visual Studio debugger wasn't showing an exception (and I've wrapped everything in try/catch blocks just in case), but I hadn't thought of trying Windbg...