I have been working on a project for a few months now and decided to update to cocos2d 1.0.0 and now my program keeps crashing on this method
[smgr morphShapeToActive:self.currentFootball.shape mass:25];
I was told by a friend that this method has been deprecated in the newer chipmunk builds. Is that true and if so how would I go about doing this method if it no longer exists. Also does anyone now where I can find out which methods are deprecated?
I'm not very familiar with SpaceManager, but that function almost certainly adds and removes shapes. Are you calling it from within a callback? You can't do that, and it may or may not have an assertion to make sure that you don't.
As far as checking if it's deprecated, what does it say in the header?
Related
First, let me explain my problem.
I work on a framework used to build ODBC drivers, and there is a bug in the .Net framework, the part which deals with ODBC drivers. I would like to put a workaround for the bug into our framework, and I'd like to make it automatic. To do this, I would need to check if the ODBC connection in question was created from a specific .Net assembly.
My idea, at a high level was at the point of creation of the connection, to walk the stack, and see if the module which was calling into the ODBC driver manager (i.e. ODBC32.DLL) was that specific .Net assembly.
Our code is native, and written in C++. I already know how to walk the stack and check modules with CaptureStackBackTrace/CreateToolhelp32Snapshot/Module32First/GetNextModule, but I think a 'naive' approach could be flakey (not to mention that .Net assemblies != Win32 modules). Is there already some 'supported' way of doing this? Unfortunately, I don't think simply detecting managed code on the stack (which is what I guess would exist, if anything close to what I need does) is enough, I need to specifically check that a specific assembly is calling into ODBC32.dll, from lower down the stack.
Even better would be if I could detect the version of the assembly, to deactivate the workaround if the issue is ever fixed.
Something that would be almost as good, would be to detect the presence of the .Net runtime if it was activated in the current process, and to activate the workaround in that case (without causing any side effects like loading the framework if it wasn't already loaded). It could have false positives, but it would be a good default.
Edit: This is the bug in question https://developercommunity.visualstudio.com/content/problem/671144/overflowexception-from-systemdataodbcodbcdatareade.html
I think the best workaround would be editing .NET's System.Data.Obdc.dll using a .NET assembly editor like Reflexil and placing it in the same folder as your executable - it should load it instead of the one in your system files.
If you want to avoid that, here's an idea of how I would handle it:
Even if you walk the stack, you'll only see pointers to where JIT compiled the function's code, which means you'll have to figure out a way to find out where BuildMetaDataInfo() is compiled.
Here's the C# code that would grab that pointer, but you mentioned that your application is native C++, so you might have to figure out some other way to do this.
typeof(System.Data.Odbc.OdbcDataReader).GetMethod("BuildMetaDataInfo", BindingFlags.NonPublic | BindingFlags.Instance).MethodHandle.GetFunctionPointer()
Once you got the function pointer, depending on how you plan on fixing this, you could either
Hook BuildMetaDataInfo and write your own / figure out a workaround
Hook SQLColAttributeW and BuildMetaDataInfo. Use BuildMetaDataInfo's hook to detect whether SQLColAttributeW is called or by it or not, or use stack walking but that might be a nightmare considering how JIT compiles code.
Pseudocode for a SQLColAttributeW hook:
std::map<DWORD, bool> activeCalls;
__declspec(noinline) void __stdcall BuildMetaDataInfoHook() {
activeCalls[GetCurrentThreadId()] = true;
OriginalBuildMetaDataInfo(); // Call the original .NET function
activeCalls[GetCurrentThreadId()] = false;
}
__declspec(noinline) void WINAPI SQLColAttributeWHook(SQLHSTMT, SQLUSMALLINT, SQLUSMALLINT, SQLPOINTER, SQLSMALLINT, SQLSMALLINT*, SQLLEN*) {
if (!activeCalls[GetCurrentThreadId()])
return OriginalSQLColAttributeW(...);
// Insert fix here
return OriginalSQLColAttributeW(...);
}
SQLColAttributeW is the native function called by BuildMetaDataInfo() that seems to be causing your issue according to what I read on the bug report you posted.
I'm using gtkmm to build a UI. The task I'm trying to accomplish is constructing a radio button from an action that is already part of a menu and a toolbar. I'd like the new button to proxy for the existing action.
One likely candidate is Gtk::Action::create_tool_item(). Its documentation states:
Deprecated: 3.10: Use a Gtk::ToolItem and associate it with a Action using Gtk::Actionable::set_action_name() instead
So, I'd expect that ToolItem and by inheritance RadioToolButton would implment this interface. In gtkmm-3.12 it does not and the stable documentation reflects this as well.
However, the C library gtk-3.0 RadioToolButton does implement this interface. So, my question is this.
Should gtkmm Gtk::RadioToolButton implement Gtk::Actionable? Is the absence of this int erface an oversight, or is there another way that the features of Actionable are supported?
There is a function, set_related_action() which associates the correct icon for the radio button. It doesn't seem to put the button into the group and it is also deprecated.
I had the same question. This is certainly not documented as clearly as it could be. But I found a thread on the mailing list (perhaps also yours!) from a few months after this one, which answers both of your main questions, and I think it's worth posting for future people following the same path.
To summarise:
Is the absence of this int erface an oversight
Of course not: it was a deliberate decision, for an extremely important reason.
or is there another way that the features of Actionable are supported?
Thankfully, yes.
The thread is here - https://mail.gnome.org/archives/gtkmm-list/2014-December/msg00002.html - and this is the official response from a primary maintainer:
However, the gtkmm version, Gtk::Button does not inherit from
Gtk::Actionable. Therefore the functionality is not available. There
is a TODO in button.h:
//TODO: Derive from (and implement) Actionable when we can break ABI.
What does that mean? I thought that gtk3 and gtkmm3 were kept in sync,
i.e. gtkmm3-3.14 would be feature-complete regarding gkt3-3.14? Is
this functionality going to be implemented (when)?
[snip]
We can't add a base class to a C++ class without breaking ABI - that
generally means causing all applications that currently use that ABI
to crash. Obviously we don't want to do that. It can be done when we
do a parallel install such as when we went from gtkmm-2.4 to
gtkmm-3.0, which did not affect currently installed applications.
You can do this in the meantime:
gtk_actionable_set_action_name(theButton.gobj(), "somename");
See:
https://developer.gnome.org/gtkmm-tutorial/stable/sec-basics-gobj-and-wrap.html.en
-- Murray Cumming
Note: that first argument needs to be GTK_ACTIONABLE( theButton.gobj() ). GLib-style objects are opaque pointers only. A C++ compiler can't implicitly convert between such forward-declared C structs (even if they contain each other as 'base classes'). Besides, because here we must cast from an 'object' (GtkButton) to an 'interface' (GtkActionable), an implicit cast wouldn't work: the interface can be located anywhere within its parent object, so the address must be adjusted during the cast. The GTK_BLAH() macros cover this.
Anyway, I digress... gtkmm 4 can break ABI with impunity, and GTK+ 4 development has begun, so the Actionable interface is now implemented by GtkButton. All or most other such TODOs requiring ABI breaks should now be resolved, too. If you find something that was missing in gtkmm 3 and has not yet been added to 4, then please submit a bug report to get it sorted.
I realize the above is not so much a specific question, and I have no code to speak of, but I feel that others also have been unable to accomplish this feat - it strikes me as one of those problems where case can be everything.
So here lies my problem. I have made the screensaver, per say, of what actually runs. Essentially what I want to do is, make it run, by itself, off the timer... and perhaps some of the associated preview window features, because we need to get it selected. Problem is, either the resources regarding this are scare, by case, or my Google-fu is just not working today. (virtually all screensaver tagged questions I found on SO were about users who either knew how to make a screensaver, or those who wanted to not make one but check on one, i.e if it started running during program execution.
Some info: Trying to make it for windows 7 (using windows 7 if it matters) using C++.
What I am asking is, how to get from my current point, where I have a normal program (i.e, start in main, do some graphics...) which loops fine by itself, but I am trying to figure out, how to make it an actual screensaver - which, unfortunately, cannot be solved simply by renaming it .scr.
Thanks if you can provide any information.
PS: I am pretty new here, and don't know to much about most things, including using SO. My last question was downvoted (I will admit, it was bad), and I am now determined to ask good questions.
this should help:
http://www.cityintherain.com/howtoscr.html
and another (with downloadable example code)
http://www.codeguru.com/cpp/g-m/opengl/article.php/c2695/OpenGL-screen-savers.htm
i hope you're familiar with the win32 api
What is the difference between the functions glGenBuffers()/glBufferData()/etc, and the functions with ARB appended to the function name glGenBuffersARB()/glBufferDataARB()/etc. I tried searching around but no one ever points out the difference, merely they just use one or the other.
Also, is it common for either function to be unavailable on some computers? What's the most common way of getting around that kind of situation without falling back to immediate mode?
glGenBuffers() is a core OpenGL function in OpenGL 1.5 and later; glGenBuffersARB() was an extension implementing the same functionality in earlier versions.
Unless you're developing for an ancient system, there's no longer any reason to use the ARB extension.
I've been using dynamic libraries and GetProcAddress stuff for quite some time, but it always seems tedious, intellisense hostile, and ugly way to do things.
Does anyone know a clean way to import new features while staying compatible with older OSes.
Say I want to use a XML library which is a part of Vista. I call LoadLibraryW and then I can use the functions if HANDLE is non-null.
But I really don't want to go the #typedef (void*)(PFNFOOOBAR)(int, int, int) and PFNFOOOBAR foo = reinterpret_cast<PFNFOOOBAR>(GetProcAddress(GetModuleHandle(), "somecoolfunction"));, all that times 50, way.
Is there a non-hackish solution with which I could avoid this mess?
I was thinking of adding coolxml.lib in project settings, then including coolxml.dll in delayload dll list, and, maybe, copying the few function signatures I will use in the needed file. Then checking the LoadLibraryW return with non null, and if it's non-null then branching to Vista branch like in a regular program flow.
But I'm not sure if LoadLibrary and delay-load can work together and if some branch prediction will not mess things up in some cases.
Also, not sure if this approach will work, and if it wont cause problems after upgrading to the next SDK.
IMO, LoadLibrary and GetProcAddress are the best way to do it.
(Make some wrapper objects which take care of that for you, so you don't pollute your main code with that logic and ugliness.)
DelayLoad brings with it security problems (see this OldNewThing post) (edit: though not if you ensure you never call those APIs on older versions of windows).
DelayLoad also makes it too easy to accidentally depend on an API which won't be available on all targets. Yes, you can use tools to check which APIs you call at runtime but it's better to deal with these things at compile time, IMO, and those tools can only check the code you actually exercise when running under them.
Also, avoid compiling some parts of your code with different Windows header versions, unless you are very careful to segregate code and the objects that are passed to/from it.
It's not absolutely wrong -- and it's completely normal with things like plug-in DLLs where two entirely different teams probably worked on the two modules without knowing what SDK version each other targeted -- but it can lead to difficult problems if you aren't careful, so it's best avoided in general.
If you mix header versions you can get very strange errors. For example, we had a static object which contained an OS structure which changed size in Vista. Most of our project was compiled for XP, but we added a new .cpp file whose name happened to start with A and which was set to use the Vista headers. That new file then (arbitrarily) became the one which triggered the static object to be allocated, using the Vista structure sizes, but the actual code for that object was build using the XP structures. The constructor thought the object's members were in different places to the code which allocated the object. Strange things resulted!
Once we got to the bottom of that we banned the practise entirely; everything in our project uses the XP headers and if we need anything from the newer headers we manually copy it out, renaming the structures if needed.
It is very tedious to write all the typedef and GetProcAddress stuff, and to copy structures and defines out of headers (which seems wrong, but they're a binary interface so not going to change) (don't forget to check for #pragma pack stuff, too :(), but IMO that is the best way if you want the best compile-time notification of issues.
I'm sure others will disagree!
PS: Somewhere I've got a little template I made to make the GetProcAddress stuff slightly less tedious... Trying to find it; will update this when/if I do. Found it, but it wasn't actually that useful. In fact, none of my code even used it. :)
Yes, use delay loading. That leaves the ugliness to the compiler. Of course you'll still have to ensure that you're not calling a Vista function on XP.
Delay loading is the best way to avoid using LoadLibrary() and GetProcAddress() directly. Regarding the security issues mentioned, about the only thing you can do about that is use the delay load hooks to make sure (and optionally force) the desired DLL is being loaded during the dliNotePreLoadLibrary notification using the correct system path, and not relative to your app folder. Using the callbacks will also allow you to substitute your own fallback implementations in the dliFailLoadLib/dliFailGetProc notifications when the desired API function(s) are not available. That way, the rest of your code does not have to worry about platform differences (or very little).