Window handle from process

Alienizer

Did you try using GetAncestor.call(handle, GA_ROOTOWNER) to ensure you get the root SketchUp window which is the owner of all SU's window? Your code might be getting a child window...

No I didn't, because my code never return a handle to begin with! It does iterate all windows, so it should pickup the pid, that's why I'm asking for help!

Alienizer

@thomthom said:

What if the user has multiple windows open with the same title? Multiple unsaved models etc?

I know, that's why I don't want to use it and want my first code to work!

Alienizer

@thomthom said:

You experienced crashes?

Yes, and it seems to have something to do with toolbars from 3rd party. When I have all of them visible (about 30 of them), your code runs for about 10 secs then SK unload from memory!

Dan Rathbun

From Ruby you can get process id, like:
$$
or
Process.pid

Alienizer

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

Dan Rathbun

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

Alienizer

@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

Alienizer

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!

Dan Rathbun

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

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.

GitHub - cosmo0920/win32-api: A different, better variant of the Win32API Ruby library

A different, better variant of the Win32API Ruby library - cosmo0920/win32-api

GitHub (github.com)

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.

GitHub - cosmo0920/win32-api: A different, better variant of the Win32API Ruby library

A different, better variant of the Win32API Ruby library - cosmo0920/win32-api

GitHub (github.com)

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.