I have a DPC class in sap for a gateway service. I redefined a getEntitySet method and wrote some code in it.
Then I accidentally undid the redefinition and all my code is gone. Is there any way to get my code back?
Is there any way to get my code back?
Yes, unless you activated it. Just redefine it again and your former code will appear in the method automatically, you don't even need to go to Versions. If you see that method in the blue state, it is not yet activated.
If you deleted the redefinition and activated the method, this is the point of no return and you've lost the code forever. Undefinition does not cause automatic version generation.
However, you can prevent such situations to happen in future by making manual version generation. Just go to Utilities->Versions->Generate version after you implemented the method and that's it.
Now even (de)activation and (un)definition is not a problem for you, you'll always have YOUR version type U in the database.
Related
I'm learning DirectX 2D.
When i close my application, i have noticed there is a problem in IWICImagingFactory* type variable.
I use only one IWICImagingFactory* variable in whole program. So i initiate it once when i start program and destroy(release) once when i close my program.
But if i release IWICImagingFactory* variable after call CoUninitialize() function, there is error.
Factorys::~Factorys()
{
SAFE_RELEASE(mpD2DFactory);
SAFE_RELEASE(mpWICFactory);
}
↓ Is is korean, meaning : error throw, access violation, "this->mpWICFactory->" is 0x6EEFC7D8
enter image description here
I noticed "this->mpWICFactory->" has problem when i try to release WICFactory after call CoUninitialize(). So i read about CoUninitialize() in here : "https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize"
And i read this part in the link : Closes the COM library on the current thread, unloads all DLLs loaded by the thread.
Quetion 1 : When i call CoUninitialize() function, WICfactory is released automatically?
Quetion 2 : Do i have to release WICFactory before call CoUninitialize() function?
Yes, as you mention in the question, CoUninitialize will unload all dependent loaded libraries (WICFactory being one of them).
So trying to unload an already unloaded library will get you an AV or another Error.
It's not "really necessary" to release WICFactory, since CoUninitialize will also do it (and since you release when program closes anyway, even if you don't call CoUninitialize the Operating System will do it for you).
However, I strongly recommend that you still release your resources (so yes, release WICFactory, then call CoUninitialize ), having code that knows how to do correct cleanup will always be better in the long term (no matter if you use smart pointers or not, that is up to you).
Short version:
What use is -removeObserver:forKeyPath:?
Why not always use -removeObserver:forKeyPath:context:?
Long version
While working on a Cocoa program, I discovered that using -removeObserver:forKeyPath: could (but would not always) lead to an error like:
Cannot remove an observer <ObservedClass 0x1001301d0> for the key path "exampleKeyPath" from <__NSCFConstantString 0x100009138> because it is not registered as an observer.
while using -removeObserver:forKeyPath:context: instead would work just fine.
Since it is required that a context be specified when setting up observation (with -observeValueForKeyPath:ofObject:change:context:), I'm puzzled at why the context:-less removal method exists.
Based on my reading of the NSKeyValueObserving Protocol, I supposed that the removal might apply to the specified observer and specified key path in all contexts, but the failure of -removeObserver:forKeyPath: (with no context) to work as a replacement for -removeObserver:forKeyPath:context: (with a context of NULL) seems to shoot down that idea.
So: why might I have that error? What does -removeObserver:forKeyPath: do with contexts? How's it differ from its context:-equipped younger sibling?
Code example
Problematic code:
-(void) invalidate {
[(id)observedObject removeObserver:self
forKeyPath:#"exampleKeyPath"];
}
Non-Problematic code:
-(void) invalidate {
[(id)observedObject removeObserver:self
forKeyPath:#"exampleKeyPath"
context:NULL];
}
Short version: -removeObserver:forKeyPath:context: was only introduced in 10.7, hence both.
Long version: Why might you have the error? Looks like a bug, either in your code or the system (I've never seen the error and use the shorter version a lot). The descriptions of the two methods do not suggest there should be any difference. If nobody else comes up with an explanation, and you can't find anything in your code, then report a bug to Apple.
The documentation has an excellent discussion as to the use of the new method:
Examining the value in context you are able to determine precisely which addObserver:forKeyPath:options:context: invocation was used to create the observation relationship. When the same observer is registered for the same key-path multiple times, but with different context pointers, an application can determine specifically which object to stop observing
It's just a way to be more specific about just which binding you want to remove from the object. For example, I might bind to a keypath twice, but with the memory locations of different static variables, a little like how dispatch_once() works. The context-free subscription method was the only way of binding to an object until 10.7 rolled around and filled in that gap.
As for your KVO troubles, the problem can occur in many different cases. The most common being that you've subscribed on one thread, then very soon after, removed a subscription from a different thread. Occasionally it can occur because the object you tried to observe was just about to deallocate, meaning you would subscribe to some bogus memory location that happened to fill what you needed to, then removing the subscription from this garbage pointer would be impossible. Either way, make sure to monitor the methods you're utilizing bindings in, as they can be a little unstable if used in the wrong way.
I have gotten this error on several occasions and am unclear as to what causes the error in general. After looking for over an hour on stack overflow and google I still don't have an answer. Could someone help?
I've seen several specific answers but nothing that says why the error happens, only "do x", or "do y".
I haven't included code yet because I want to know the reason that this error happens in general so I can fix my code in the future whenever I get this error.
There are lots of reasons it could happen, but generally it's saying that at the line of code it flags, it doesn't see any evidence that the selector you are referencing is in the interface of the type it thinks the object has.
In this example,
No visible interface error
They declared operandStack with the wrong type.
In this one
http://www.raywenderlich.com/forums/viewtopic.php?f=2&t=3312
They had a typo in the selector name
Any chance you are on Xcode 4.2 (or less), running code that was written on Xcode 4.3? In 4.3+ Xcode doesn't require you to declare private methods at all, it just assumes that methods written in the implementation file (without declarations in the interface) are private. But in Xcode <= 4.2, this will throw an error and those methods need to be at least declared privately
I just had this problem; mine was caused by me setting the method as a class method rather than an instance method. Very silly.
Another reason can be when using categories in libraries and you haven't set -ObjC (or -all_load) in the Other Linker Flags
Another common error ist to forget to write [someInstance setSomeValue:3]; instead of [someInstance someValue:3] (<- wrong). That what happened to me.
When I have run into this problem it turned out that Xcode had not reindexed files after changing Git branch. The solution is Delete Derived Data.
Using Xcode version 10.0 File -> Workspace Settings...(or Project Settings...) -> click on the little green circle and manually remove all files in DerivedData folder
I had this problem with NSSavePanel -beginSheetModalForWindow::, which obviously exists. I tried doing a clean rebuild as well as deleting the DerivedData, but no luck. I had copy-pasted and then modified, but I commented that out and typed out the call to -beginSheetModalForWindow and it started working. As far as I can tell I did not have any mistakes in the original call.
I'm looking to use FSPathCopyObjectAsync and I'm failing. In order to get my head around the problem I've been looking for examples of it elsewhere and although I was experimenting with the slightly dated source code from Matt Long's tutorial over on Cocoa is my Girlfriend, I then found a bit more elaborate example in a project on github, as a category on NSFileManager. Since my project is running under ARC, I tried porting it, and succeeded only at the half of it.
In its current form, the actual copying works, yet the callback method MZCopyFSPathFileOperationStatusProc is never called. That callback method happens to be the sole reason for using asynchronous copying, otherwise one might as well run a synchronous one in the background. I'm assuming the reason for the callback not being called is that some object is incorrectly released by ARC, but there could be something else going on. I am holding on to the return object of the copyItemAsyncAtPath:toPath:destName:options:statusChangeInterval:error: method, so that can't be it, right?
Who can spot the error and explain why this category isn't generating any callbacks? Is it ARC? Is it something else?
Much obliged. EP.
P.S. For redundancy reasons, here is the gist: https://gist.github.com/6f3715753896ccf6fd35
Your delegate needs to be strongly referenced by something. NSFileManager will only hold a weak reference to it (as it should do), so if you don’t have a strong reference to it, your delegate will get released and the callbacks won’t be seen.
Have you considered using blocks for the callbacks? That would probably be preferable.
i am working on an application which calls the COM component of a partner's application. Ours is .Net, theirs isn't. I don't know much about COM; I know that the component we're calling is late-bound i.e.
obj As Object = CreateObject("THIRDPARTY.ThirdPartyObject")
We then call a method on this COM object (Option Strict Off in the head of the VB file):
obj.AMethod(ByVal Arg1 As Integer, ByVal Arg2 As Integer, ByVal Arg3 as Boolean)
I am a bit nonplussed that even though this call works, this overload doesn't exist in the COM interop .dll that is created if I instead add a reference to the COM server using Add Reference. The only available call to this method that it says is available is AMethod().
However, this in itself is not what bothers me. What bothers me is that this call works for a while, THEN throws a TargetParameterCountException after a few dozen calls have executed successfully.
I ask thee thus, StackOverflow:
What. The. Hell.
The only thing I can guess at is that the documentation for the COM component states that this method is executed synchronously - so therefore maybe whatever's responsible for throwing that exception is being blocked until some indeterminate point in time? Other than that, I'm completely stumped at this bizarre, and more importantly inconsistent behaviour.
edit #1:
More significant information that I've just remembered - from time to time the call throws an ExecutionEngineException instead. It only took one glance at the documentation to realise that this is VERY BAD. Doing a little bit of digging suggests to me that the late-binding call is causing stack corruption, crashing the entire CLR. Presumably this means that the runtime is shooting down bad calls (with TargetParameterCountException) some of the time and missing them (ExecutionEngineException) others.
edit #2:
Answering David Lively's questions:
The call with zero arguments that's currently in the code has been there for a long time. I haven't been able to get hold of a manual for the third party's COM implementation past two major revisions ago, so it's possible that they've withdrawn that signature from service
There is only one location that this method is called from
This is one desktop app calling another, on the same machine. Nothing fancy
The object is persisted throughout the scope of the user's interaction with the application, so there's never a new one created.
Unfortunately, it seems likely that there is indeed a bug in the implementation, as you suggest. The trouble with this vendor is that, when we report a bug, their response tends to follow the general form: i) deny there's a problem; ii) deny it's their problem; iii) refuse to fix it. These three steps tend to span a frustratingly long period of time.
No, it can't cause stack corruption. IDispatch::Invoke() is used to call the method, the arguments are packaged in an array. The stock implementation of IDispatch certainly would detect the argument mismatch, it uses the type library info to check. But it is conceivable that the COM server author implemented it himself. Imperfectly. It is something a C++ hacker might do, the stock implementation is dreadfully slow. The GC heap getting corrupted is the kind of thing that happens when imperfect code executes.
I haven't played with calling COM objects from VB in quite a while, but I'll take a wild guess:
I would expect an exception to be thrown if you're calling the object with too few or too many arguments, but it appears that's not the case. What is the real signature of the method you're calling?
In some languages and some situations, when you call a method, arguments are placed on the stack. If you place too many arguments, it's possible for the extraneous ones to remain on the stack after the method completes. This should cause lots of other problems, though.
Some possibilities/considerations:
The object is throwing this exception internally. This should be taken up with the author.
You're calling with too many parameters. If, as you said, the overload you're trying to call isn't published in the object's type library, you may actually be calling a different published method with a different signature. I'd REALLY expect a compiler error if this is the case.
Are your later calls taking place in the same part of your code, or is there a different execution branch that might be doing things a bit differently, and causing the error?
Are you running this from a desktop app/script, or a website? If a website, are you receiving a valid, expected response, or does the request hang as if an internal long-running process doesn't complete?
The object may be allocating and not releasing resources, which could cause undefined behavior when those resources are exhausted.
Are you releasing the object between calls, or is it recreated every time?
Also, re: your comments about late binding: the .CreateObject() method of instantiating a COM object is the normal, accepted way to do this. That shouldn't have anything to do with the issue. Based on the exceptions you listed, I'm strongly inclined to believe that there is an internal issue with the object.
Good luck.
OK, basically - false alarm. I've done it wrong - I've copied some code over from somewhere improperly and the thing I'm calling was never supposed to support that overload. What I find interesting is that the component didn't reject that late-bound call out of hand, but did everything it was supposed to do, at least initially.