Window handle from process
-
From Ruby you can get process id, like:
$$
or
Process.pid
-
@dan rathbun said:
From Ruby you can get process id, like:
$$
or
Process.pid
That worked I should have used GetCurrentProcessId instead of GetCurrentThreadId but your way is much simpler. Thanks!
-
Using "Untitled" as a substring only works in English editions.
In other editions it's bound to be a unicode string.
The Win32 Resource ID in the sketchup.exe String Table is 61443 (in case you like using a LoadString system call.)
-
@dan rathbun said:
Using "Untitled" as a substring only works in English editions.
True!
@dan rathbun said:
The Win32 Resource ID in the sketchup.exe String Table is 61443 (in case you like using a LoadString system call.)
Thanks.
But I don't think my approach or that of thomthom to get the SKP window works. If you use Process.pid and enum the windows until you find the right one, and use GetWindowText WinAPI to get the title of the SKP window, it works, but not always. I have a shortcut to SKP in one of my folder and it works to get the title, but if I use the Windows Start menu to run SKP, the title is blank, so it's not getting the proper window as expected. And since the return text is blank, we can't tell which window it is!
So try it using the following...
wnd = getAncestor.call(wnd, 3) buf = "\0" * 260 getWindowText.call(wnd, buf, 256) UI.messagebox(buf.strip)
or the complete code...
getTopWindow = Win32API.new('user32.dll', 'GetTopWindow', 'l', 'l') getWindow = Win32API.new('user32.dll', 'GetWindow', 'li', 'l') getWindowThreadProcessId = Win32API.new('user32.dll', 'GetWindowThreadProcessId', 'lp', 'l') getWindowText = Win32API.new('user32', 'GetWindowText', 'LPI', 'I') getAncestor = Win32API.new('user32', 'GetAncestor', 'LI', 'L') tid = Process.pid wnd = getTopWindow.call(0) pid = 0.chr * 4 while wnd != 0 getWindowThreadProcessId.call(wnd, pid) pidnum = pid.unpack('L').first if pidnum == tid wnd = getAncestor.call(wnd, 3) buf = "\0" * 260 getWindowText.call(wnd, buf, 256) UI.messagebox(buf.strip) break end wnd = getWindow.call(wnd, 2) end
-
I found the answer to my own problem! I was running the code inside my class
I don't know why it makes a difference!
-
You should always be running your wrapped within a module.
The problem with TopWindow is that if a user has wxSU installed, the Sketchup window will be wrapped in a WX::Frame, and wxSU resets the Sketchup app window to have the invisible frame as it's parent.
There are other quirky title things. If a user double clicks a SKP file to start Sketchup, the Title will not have "Untitled" (in the local language,) but could have a filename with unicode characters, and if it's Sketchup Pro, there's a bug where it does not have the "Pro" part until after it finishes processing the Plugins and Tools folders, and draws to UI (toolbars and menus.)
I rejected this window title approach as too problematic:
# find_skp_hwnd_by_title(debug=false) # # Try to find app window by title. # # Highly modified from wxSU code. # def find_skp_hwnd_by_title(debug=false) require('Win32API.so') skp_window_id = 0 findWindow = Win32API.new("user32.dll", "FindWindow", ['P','P'], 'N') # Set locale specific "Untitled" string Hash # # ** this won't work as is because some strings are unicode # notitle = Hash.new("Untitled") notitle['cs'] = "NĂĄzvu" # Czech notitle['de'] = "Unbenannt" # German notitle['en'] = "Untitled" # English notitle['en-US'] = "Untitled" # English notitle['es'] = "Sin tĂtulo" # Spanish notitle['fr'] = "Sans titre" # French notitle['it'] = "Senza titolo" # Italian notitle['nl'] = "Titelloze" # Dutch notitle['pl'] = "Niezatytulowane" # Polish notitle['pt-BR'] = "Sem tĂtulo" # Portuguese-Brazil notitle['pt'] = "Sem tĂtulo" # Portuguese notitle['tr'] = "Basliksiz" # Turkish # These strings are reportedly not translated sketchup_free = "SketchUp" sketchup_pro = "SketchUp Pro" no_license = "[LICENSE UNAVAILABLE]" # Find the SketchUp main window handle by its window title model_path = Sketchup.active_model.path if (model_path.empty?) model_name = notitle[ Sketchup.get_locale ] if (Sketchup.app_name == "Google SketchUp") sketchup_title = model_name + " - " + sketchup_free else sketchup_title = model_name + " - " + sketchup_pro end else # For some reason, when starting SketchUp Pro by double-clicking an SKP # file, the window title says SketchUp until after load is complete. model_name = File.basename(model_path) sketchup_title = model_name + " - " + sketchup_free end skp_window_id = findWindow.call(0, sketchup_title) if debug && skp_window_id == 0 msg = "Sketchup Window could NOT be found with title;\n #{sketchup_title}" msg<< "\n\nWill search for No license version.\nClick OK to continue..." UI.messagebox(msg) else UI.messagebox("Sketchup Window found with title; #{sketchup_title}") end if (skp_window_id == 0) # Can't find the window, look for no license version skp_window_id = findWindow.call(0, sketchup_title + " " + no_license) if debug && skp_window_id == 0 UI.messagebox("Sketchup Window could NOT be found with title; #{sketchup_title}") else UI.messagebox("Sketchup Window found with title; #{sketchup_title}") end end return skp_window_id end # def
-
I agree 100% with you.
BTW, when SKP runs your rb scripts, is the rb script first compiled by the Ruby interpreter, or is it interpreted like the old DOS Basic? Or compiled to P-Code?
-
Well it's not called a "compiler" is it?
-
@dan rathbun said:
Well it's not called a "compiler" is it?
No, but I doubt it interprets characaters by characters at run time, it would be too slow. It has to pre-compile or something.
-
Well the actual Ruby Core modules, classes and methods, are themselves compiled C-functions.
The interpreter just "gathers" the arguments from the plain text scripts, and makes the C calls in the background.If you have downloaded the Ruby C source... you can read the interpreter's source to get an idea of what's happening behind the scenes.
-
@dan rathbun said:
you can read the interpreter's source to get an idea of what's happening behind the scenes.
yeah! I've done that once with the RH Linux source. It's difficult when you're not the one who wrote it. It's easier to ask
Going back to this SKP window handle thing, sometime it doesn't work when I double click on an SKP file. But it always work using the shortcut! I don't have wxSU installed. What do you think it could be?
-
Dan, Tom, Alienizer,
Sorry to pop up in this intersting discussion.
Does it mean there is a Win32api.so working for both Win32 and Win64 (Vista and 7)? I have problems with my current Win32Api version on Windows 7 - 64 bits.
Thanks
Fredo
-
@unknownuser said:
Does it mean there is a Win32api.so working for both Win32 and Win64 (Vista and 7)?
Apparently not, it's all 32bit only but Win32api.so works just fine in Win7/64 and Vista/64, so as in XP/64
-
@alienizer said:
Apparently not, it's all 32bit only but Win32api.so works just fine in Win7/64 and Vista/64, so as in XP/64
OK. Thanks. Then it must an issue with Jim's Ruby console (but I modified the code, so it may be my fault)
Fredo
-
@alienizer said:
Going back to this SKP window handle thing, sometime it doesn't work when I double click on an SKP file. ... What do you think it could be?
While Sketchup starts up, and is processing the rubies in the Plugins and Tools folders, the UI is not yet finalized. The menus and toolbars are not built until all rubies that modify or create toolbars have been processed.
It seems that the window title bar is also not finalized. If you have Sketchup Pro, when you double-click a SKP file, during the startup, the window title bar says "clickedfile.skp - Sketchup". It's not until the UI is finalized that it reads "clickedfile.skp - Sketchup Pro".
BTW.. I have a solution that Always works (on Windows,) even if more than one Sketchup instance is running. Just need to decide how to implement it. (ie: modify a API module, put it an SKX submodule, or put it in a module of my own.)
-
There are some quirks with some of the version system calls... look thru the source code for Daniel Berger's win32-api package.
https://github.com/djberg96/win32-api
and
https://github.com/djberg96/windows-pr
Some system calls were added for ver 6+ (dealing with the registry,) and some are not supposed to used with ver 6+.
You can look at the issues, and you'll see a list of registry system calls that I help him out with, that he added to the package. (In case you don't want to d/l the source.)ADD: Here's the issues link if interested:
https://github.com/djberg96/windows-pr/issues?direction=desc&sort=created&state=closed -
@dan rathbun said:
There are some quirks with some of the version system calls... look thru the source code for Daniel Berger's win32-api package.
https://github.com/djberg96/win32-api
and
https://github.com/djberg96/windows-pr
Some system calls were added for ver 6+ (dealing with the registry,) and some are not supposed to used with ver 6+.
You can look at the issues, and you'll see a list of registry system calls that I help him out with, that he added to the package. (In case you don't want to d/l the source.)ADD: Here's the issues link if interested:
https://github.com/djberg96/windows-pr/issues?direction=desc&sort=created&state=closedThanks! I'll have a look.
-
@dan rathbun said:
While Sketchup starts up, and is processing the rubies in the Plugins and Tools folders, the UI is not yet finalized. The menus and toolbars are not built until all rubies that modify or create toolbars have been processed.
Is there a way to "wait" until SK is loaded? I'm not using the title bar caption to find the window, I'm using Process.pid and iterate all windows to match the pid.
-
@alienizer said:
Is there a way to "wait" until SK is loaded?
Not exactly. (I've been working on a utility to do just that. Not yet happy with it.)
On Mac it may be easier, as it does not open a new blank model until after processing the rubies. (On Windows, a new blank model is opened, before processing the startup scripts.)
A workaround that scripters use is the
UI.start_timer
block.
However that can be defeated if any other script has aLoadError
. The modal "LoadError" dialog pops up, and you never know how long it will take for the user to read and then dismiss the dialog. -
One way that seem to work for me now is...
Using the code to find the SK window using the pid, get the window text, and if =~ /SketchUp/i then you have the right one, otherwise, set the window handle to nil and when your ruby code gets called for whatever reason, test if the window handle is nil, and it it is, re-get it again, then continue execution.
So far, this way has worked for me all night, running 3-5 instances of SKP, and running them using direct, shortcuts, skp docs, via an exe and all. It worked even when other ruby script has errors.
Advertisement