I want to copy a file to a FTP server using wxFTP, but I would like to do this without blocking the UI, and much better, while displaying a progress bar. Can I do this without extra thread?
I'm using wxLua, but I can adapt a solution written in any language as long as it uses a wxWidgets binding.
Try using wx.lib.delayedresult. It's available in wxPython, but maybe also it is in your wxWidgets library too. It creates separate worker thread and is called with a consumer function that is called once worker thread finishes his job. Quite useful thing.
See wxPython docs for details.
What's wrong with starting your own Thread for this?
You could check the streams canRead() method periodically (through a timer or in the event loop, maybe) and only read when it returns true, but it'll probably be a lot more complex than just starting a separate thread.
Related
in my project i injected a DLL(64-bit Windows 10) in to a external process with Manual-map & Thread-hijacking and i do some stuff in there.
In current state i use "RtlCreateUserThread" to create a new thread and do some extra workload in there to distribute it for better performance.
My question is now... Is it possible to access other threads from the current process (hijack it) and add your own workload/code there. Without creating a new thread?
I didn't found anything helpful yet in the internet and the code i used and modified for Thread-hijacking seems to only work for a DLL file. Because i am pretty new to C++ i am still learning i am already thankful for any help.
(If you want to see the source for injector Google GHInjector your find the library on github.)
It is possible, but so complicated and may not work in all cases.
You need to splice existing thread's machine codes, so you will need write access to code page memory.
Logic:
find thread id and thread handle, then suspend thread with SuspendThread WINAPI call
suspended thread can be in wait state or in system DLL call now, so you need to analyze current execution stack, backtrace it and find execution address from application space. You need API functions StackWalk, and PDB files in some cases. Also it depends on running architecture (x86, amd64, ...). Walk through stack until your EIP/RIP will not be in application memory address space
decode machine instruction (it will be 'call') and splice next instructions to your function call. You need to use __declspec(naked) declared function or ASM implemented one for execute your code and replaced instructions.
ResumeThread
This method may work only once because no guarantees that application code is executed in loop.
I would like to create a wxPython app such that:
If I run a second instance of that app (e.g., call the Python script from the shell a second time), no new instance should be created.
Instead, the toplevel frame of the already running instance should be raised and focussed.
The first point can be easily implemented by wx.SingleInstanceChecker (see the example code there), but at least the example code only gives a way for making the second instance of the app abort, but not raise the existing app's main frame.
I am using wxPython-Phoenix with Python 3.
Claritication: I would much prefer an out-of-the-box solution like wx.SingleInstanceChecker (that is, not implement my own locking and IPC solution).
You can use any kind of IPC to send a message asking the other program to do whatever needs to be done (just raise its top level window or maybe handle the command line options passed to the second instance). In C++ there are wxConnection and the related wxServer and wxClient classes that can be used for this, but I'm not sure if they're wrapped by wxPython -- however you could use any Python IPC module instead, if they aren't.
As has been pointed out, the "correct" way to do this is IPC because you have a new process that is supposed to affect a change (raise and focus) in another process.
What you seem to want is to take advantage of the IPC channel that wx.SingleInstanceChecker is already using to do your work. Unfortunately, you can't. That class is implemented in the wxWidgets c++ code and therefore there are no Python bindings to the internal workings of the class.
However, you can probably abuse wx.SingleInstanceChecker to do what you want. In your program, you can set up a timer at some rapid interval (say, 250ms) that will constantly check IsAnotherRunning() from your main process. Therefore, when your second process starts up, the first will notice and can raise itself to the front. You would just have to wait for a little bit in the secondary process before it exits, to give the first time to notice.
I am on macOSX (Sierra), not iOS, Objective-C, Xcode9.
I have an application with implemented applescript classes, XCode compiles them for me. Whenever i call an applescript method from within an *.m file (and from a background thread!) i dispatch_sync it to the main thread (as applescript needs to be executed in the main thread) - sync cause i need the result to continue.
I'd like to show you with a simple example:
Applescript:
on openFile_filePath(filePath)
try
tell application "Adobe InDesign CC 2018"
set myDoc to open (filePath as string)
return id of myDoc
end tell
end
return 0
end
Objective-C
// Method is running in a background thread
// appleScriptHelper is properly instantinated
__block NSInteger docID = 0;
NSString* someFile = #"/Users/user/Desktop/";
dispatch_sync(dispatch_get_main_queue(), ^{
docID = [self.appleScriptHelper openFile:someFile];
});
This runs smooth - as long as InDesign responds! Sometimes, InDesign freezes and then my whole app freezes cause it basically waits forever on the main thread.
What i tried:
I cannot use a timer cause the main thread is blocked anyways and i cant pass a "cancel" message - cause Applescript is busy anyways waiting for something never happen.
In addition it is not possible to work with "with timeout of x seconds" in applescript when compiled from XCode (just doesnt work as mentioned in other posts).
I tried it with NSOperations but as i need to dispatch to the mainThread... still the same issue.
So my question is: Is there any way i can STOP the whole dispatch_sync block after a time of x seconds? Or is there any other possibility to keep the app running and not being locked up forever through InDesign freeze?
Note: The implementation works fine - please don't recommend 'use NSApplescript' or 'use Scripting Bridge'.
Reasons: ScriptingBridge - it's almost impossible to create a working HEADER file for InDesign (it almost weights 15 MB and throws tons of compiler errors - i did fix that once with lot of manual work just to see it not working anymore for the next Version of InDesign). NSApplescript is fine as long as you have simple scripts which is not the case.
Any help appreciated
Were NSAppleScript sufficient for your needs, I'd say use NSUserAppleScriptTask which runs scripts out of process with async completion callbacks. And yes, as you say, Scripting Bridge is utterly unfit for non-trivial automation, especially any involving large complex crusty Carbon apps like Adobe's, so don't waste a second on that.
There is AppleEventBridge/SwiftAE, but with Apple shuffling off the whole AS/AE infrastructure to quietly die off, I don't promote or support those any more, so maxima caveat emptor. (I still use Python appscript for my own Adobe app automation,btw, and it continues to blow everything else out the water, but I won't be surprised if the whole industry eventually goes Windows as the only professional-oriented platform left.)
..
The problem with using AppleScript-ObjC* is that AppleScript component (aka interpreter) instances are not thread-safe: you can instantiate them on any thread you like, but you can only use them on that thread, not from others. ASOC doesn't let you control any of this stuff for yourself; neither does NSAppleScript. (OSAKit does, but it's as painful to use as NSAppleScript is.) So ASOC code is de facto limited to running on the main thread only.
If you're stuck with using ASOC, I think your best bet is to push that code out into a subprocess that your main process talks to asynchronously via XPC Services or whatever. That'll avoid blocking your main process's main event loop (which then blocks its GUI) while allowing ASOC to do its own thing independently.
p.s. Another problem with ASOC is that changes in 10.13's bridgesupport files have changed/broken how C APIs are mapped to AS, which can break existing ASOC-based scripts. (I've stopped recommending ASOC unless/until that's fixed.)
Basically, how can I make sure that in my module, a specific process is current. I've looked at kick_process, but I'm not sure how to have my module execute in the context of that process once kicking it into kernel mode.
I found this related question, but it has no replies. I believe an answer to my question could help that asker as well.
Note: I am aware that if I want the task_struct of a process, I can look it up. I'm interested in running in a specific context since I want to call functions that reference current.
Best way i have found to do anything in the context of a particular process in the kernel, is to sleep in process context(wait_* family of functions) and wake up that thread and do whatever needs to be done in that context. This would ofcourse mean you would have to have the application call into the kernel via IOCTL or something and sleep on that thread and wake it up whenever you need to do something. This seems to be a very widely used and popular mechanism.
I have a small application that needs to update GUI elements if some event occurs in lower levels, say, socket goes off-line, or something like that.
In Windows, I could use PostMessage which would be sent through the chain to all Windows, and the required ones could update accordingly.
How can I achieve something similar in wxWidgets? I cannot use OnUpdateUI, or something like that, because some controls doesn't seem to handle that at all.
The target window could be one or multiple, they could be frames or controls, so I'm confused a little here.
Does anyone have a suggestion?
First, all controls do receive EVT_UPDATE_UI so you could use it for this and it's a very simple of doing it -- but also the most inefficient, so definitely not recommended for something like socket event processing (it's fine for checking whether the socket is connected or not though).
Second, the exact equivalent of Windows ::PostMessage() is wxQueueEvent() (which used to be called as wxPostEvent() actually but the new version is preferable). wxQueueEvent() is thread-safe in the sense that it can be used from a secondary thread to post an event to a GUI control managed by the main thread.
You can use the same approach as in Win32 apps. You can create the custom event class and send it to windows using wxPostEvent function. There are some docs regarding this.
Not sure what you mean about wxUpdateUIEvent - from my experience it works pretty fine. What controls do not receive it? Did you add EVT_UPDATE_UI() macro to event table?