I've encountered a really strange behavior which I try to understand.
While developing an iOS App using Xamarin, and two 3rd party libraries (One is a credit card reader - UniMag and a barcode scanner).
I am adding observers:
var center = NSNotificationCenter.DefaultCenter;
center.AddObserver ("uniMagAttachmentNotification", Attached);
center.AddObserver ("uniMagDidConnectNotification", Connected);
center.AddObserver ("uniMagSwipeNotification", SwipeReady);
center.AddObserver ("uniMagDidReceiveDataNotification", DataProcess);
center.AddObserver ("uniMagSystemMessageNotification", UnimagSystemMessage);
center.AddObserver ("uniMagDataProcessingNotification", DataProcessNot);
center.AddObserver ("uniMagInvalidSwipeNotification", InvalidSwipe);
center.AddObserver ("uniMagSwipeNotification", SwipeNotification);
If I have a breakpoint in
void SwipeNotification (NSNotification notification)
{
string justForTheBreakPoint = "f";
}
then everything works fine, if I remove it, then it's not. The app doesn't crash, just don't work as expected. I know its vague.
My question is, what does a breakpoint actually do that can effect the behavior of the app?
Usually when putting a breakpoint fixes an issue, means you have threading problems. By putting a breakpoint you're disrupting a running thread and allowing the other parallel threads to run.
Related
Using Xcode8 Beta my simulator crashes when using an inputAccessoryView and adding the line self.view.layoutIfNeeded() in the getter of the inputAccessoryView override. It works fine on my devices but this one line causes the simulator to crash everytime
override var inputAccessoryView: UIView? {
get {
self.view.layoutIfNeeded()
return customToolbar
}
}
The following message is displayed in the console:
libc++abi.dylib: terminating with uncaught exception of type NSException
If I just remove the line: self.view.layoutIfNeeded() it will work fine on the simulator. I need that line though or else the collectionView momentarily bounces as the inputAccessoryView keyboard change notification is called.
You are probably fall into new layout loops. See changes in iOS 10 API here https://developer.apple.com/library/content/releasenotes/General/RN-iOSSDK-10.0/
Third party apps with custom UIView subclasses using Auto Layout that override layoutSubviews and dirty layout on self before calling super are at risk of triggering a layout feedback loop when they rebuild on iOS 10. When they are correctly sent subsequent layoutSubviews calls they must be sure to stop dirtying layout on self at some point (note that this call was skipped in release prior to iOS 10).
I am trying to develop certain extension for Desktop Window Manager. I selected method of DLL injection and function hooking. It is supposed to be working in Windows 7 and Windows 8.
I successfuly injected my DLL into dwm.exe process and hooked Direct3D device creation (D3D10CreateDevice1 on Win7 and D3D11CreateDevice/D3D11Device::GetImmediateContext on Win8). However, I have problem with hooking drawing procedures (Draw/DrawIndexed/etc.).
Whenever I replace pointers in vtable with pointers to my functions, they are restored back to original pointers in a while. Probably there is some hook protection in DWM/Direct3D??? I tried creating background thread which replaces the pointers still around. It works on Win7 but rarely on Win8 (it seems that pointers are restored more quickly there)
void thread(void* _device)
{
ID3D10Device1* device = (ID3D10Device1*)_device;
while(threadRunning)
{
if(device->lpVtbl->Draw != My_ID3D10Device1_Draw)
{
DX_METHOD_HOOK(device, ID3D10Device1, Draw);
DX_METHOD_HOOK(device, ID3D10Device1, DrawIndexed);
}
}
}
Does anyone have any experience with hooking and could he provide me some help? Thank you very much!
To stop my application from flickering, I tried to activate DoubleBuffering for all of my controls and subcontrols.
To achieve this, I added the follwoing codesnippet in my mainform:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000; //WS_EX_COMPOS
return cp;
}
}
The problem is, that with WindowsXP the cpu-load becomes almost 100% and keeps up. No problem on Windows7.
It looks for me, as it is the very same problem as in this question. Is there a "easy" solution in C#? Or asked in a different way -> What usually causes this behaviour? So I can find out the problem in my application.
UPDATE: Maybe some more information to help you folks help me. What I am trying to do is showing a semi-transparent form ontop of the mainform with an progressbar. This "progressBarForm" is in a second thread to have this progressbar running. On Win7 everything works fine, as mentioned above with WinXP (.net4, activated desktoptheme) there is 100% cpu-load after the progressbar was shown once - also the acutal payload-function needs much longer to complete - maybe because of the high-cpu-load done by the progressbar. Where and what should I check again? Some ideas?
Btw.: I don't think the thread is a problem, as when I show the form in the mainthread and don't refresh anything, the result (high cpu-load) is the same...
Here is something strange concerning AutorotateToInterfaceOrientation.
In the Debugger console I get this message for one of my view controllers :
The view controller returned NO from
-shouldAutorotateToInterfaceOrientation: for all interface orientations. It should support at least one orientation.
But in reality the rotations works perfectly well. And the message is wrong. Here is the code for -shouldAutorotateToInterfaceOrientation:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
return ([centerPoint autoRotateFlag]||(interfaceOrientation==centerPoint.userOrientation));
}
And either autoRotateFlag is simply true (YES), or if it is not centerPoint.userOrientation has been fixed to one of the four acceptable value.
This has been working for me for a long time and the app still works. I just don't know where this message is coming from.
Any idea?
By putting some tracing in my software, using NSLog; I realized that
shouldAutorotateToInterfaceOrientation was called seven times before
viewDidLoad was called.
Since my variable 'autoRotateFlag' is only initialized when passing through viewDidLoad. That explains my problem.
I have to admit though, that I was far from thinking shouldAutorotateToInterfaceOrientation could be called before viewDidLoad.
Obviously I was wrong. And I still do not fully understand the order in which all those methods are called.
I'm trying to learn Vala so I'm making a small GUI application. My main language before has been C# so things are going pretty well.
However, I've hit the wall now. I need to connect to an external network server (using GIO) which doesn't answer my client immediately. This makes the GUI freeze up while the program is connecting and doing its thing.
In C# I would probably use a BackgroundWorker in this case. I can't seem to find anything like it for Vala though.
Basically, I have a MainWindow.vala where I have hooked up a signal for clicking a certain button to a method that is creating a new instance of ProcessingDialog.vala. This shows a dialog over the MainWindow that I want the user to see while the program is doing the work (connecting to the server, communicating).
What are my alternatives to make this scenario work?
GIO offers async methods, see an async client for example: https://live.gnome.org/Vala/GIONetworkingSample
If you are not aware of async methods in Vala, try looking at the tutorial: https://live.gnome.org/Vala/Tutorial#Asynchronous_Methods
lethalman's answer above probably makes the most sense, an async request is really going to be your best bet if you're doing a network call. In other cases, you can use Vala's built in thread support to accomplish a background task. It looks like soon enough, there will be a better library available, but this is what's stable.
// Create the function to perform the task
public void thread_function() {
stdout.printf("I am doing something!\n");
}
public int main( string[] args ) {
// Create the thread to start that function
unowned Thread<void*> my_thread = Thread.create<void*>(thread_function, true);
// Some time toward the end of your application, reclaim the thread
my_thread.join();
return 1;
}
Remember to compile with the "--thread" option.