Window handle from process

Alienizer

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?

Dan Rathbun

Well it's not called a "compiler" is it?

Alienizer

@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.

Dan Rathbun

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.

Alienizer

@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?

fredo6

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

Alienizer

@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

fredo6

@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

Dan Rathbun

@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.)

Dan Rathbun

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

Alienizer

@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=closed

Thanks! I'll have a look.

Alienizer

@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.

Dan Rathbun

@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 a LoadError. 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.

Alienizer

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.

Dan Rathbun

What happens if a user has the Custom Toolbars plugin installed, and the "Sketchup" toolbar is visible and floating?

TIG

Can't you can simply 'assemble' the current SKP's Sketchup window's top bar 'displayed text' from Sketchup.is_pro? and Sketchup.active_model.title - ''=='Untitled' ?. Then test a window with that exact same 'name' ?
I know, what if the user has two 'Untitled' SKP's open? Just shoot him! [or post an error message and exit].
OR perhaps even pre-test the current SKP with if Sketchup.active_model.path=='' then insist on it being named/saved before your tool is run ?
I know they could still have two SKPs open from different folders which could have the same 'title'... but now I am getting tired

Dan Rathbun

@@Alan

Are you working on a free or paid plugin?

Do you want to get the current Ruby (Sketchup) process' application window from the Ruby side, or the C-side ??

Alienizer

@dan rathbun said:

@@Alan Are you working on a free or paid plugin?

Neither! But if I can make something usefull, it will be free. I'm kind of learning right now, until I'm good enough to give something.

@dan rathbun said:

Do you want to get the current Ruby (Sketchup) process' application window from the Ruby side, or the C-side ??

Either way is fine. I only need to know this to set the parent window of my dll forms. So if ruby knows it, I can pass it along to my dll. But if I can get it directly from my dll, that's good too.

Dan Rathbun

@alienizer said:

I only need to know this to set the parent window of my dll forms.

I wonder the hWndParent param is optional in most of those window create functions.

If a Thread (of a Process) creates a window, where the parent is not specified, does it default to the TopWindow of the Process, in this case the Sketchup application window ??
.. or does the Desktop become the parent ??

When a Process is destroyed (and all it's Threads,) does the system automatically destroy all the windows that the Process created ??
.. I think the answer is NO because I was able to make a UI.messagebox popup window, appear from within a Sketchup::AppObserver onQuit() callback, that stayed displayed, even after all the other Sketchup windows (incl. the main window,) had been destroyed.
The system did not like it, and I think the BugSplat! window popped up after dismissing the messagebox. I did, of course, log it as a bug for the Sketchup::AppObserver class. (Actually the bug is that Sketchup does not wait until the onQuit callbacks have completed, before shutting down.)

Alienizer

It default to the desktop window if a parent is nil. By setting the parent window (SKP), you are sure to get the WM_QUIT message when SKP is closed. hWndParent is optional, but again, the desktop becomes the parent if hWndParent is nil.