Discussion: Working with Windows' Windows (hWnd etc)

[Sedrick]

Thread split from Passing In Some Data to MS Access When Open Database.

ADezii,

That SaveSetting() and GetSetting does look useful to me for some applications though. I would be interested in how you put it to use.

Thanks!

[ADezii]

@Sedrick:
Would passing the Windows Handle of the Calling Access Main Window do the trick? This can be accomplished via:

Application.hWndAccessApp

P.S. - Window's Handles are Unique Long Integers.

[Sedrick]

ADezii,

Now you've got me thinking. (That could be dangerous).

I've never used Application.hWndAccessApp. In doing a little bit of checking, I can see it provides a unique identifier of the main Access window but I'm not sure yet how the called database could use it to determine the UserID in the calling database.

It seems like there are times when it would be handy to be able to dynamically communicate between two database instances. I know that you can create a new instance object of another database from one database, but is is possible at all to use the "Set" command, for example in the called database to create a reference to the existing calling database object? Seems like if you could somehow get that, you would have everything currently going on in the calling database available to the called database. You could read the values of a public variable, for example that would contain the UserID.

I tried this but all I could come up with was creating a new instance of the calling database where of course you cannot get at any existing objects or variables in the calling database object.

Are there any services available to MS Access, possibly using Application.hWndAccessApp to do this?

[NeoPa]

Application Automation may help with that. Not specifically, but it may provide an outline understanding. I would look into GetObject() if I were looking to do what you seem to be.

PS. I should mention that, from the original question, this appears to be over-complicating things. What you need is perfectly adequately provided by passing a parameter value into the database as you open it. Not that it's not interesting in its own right of course, but unless I misunderstand your original requirement (which is the topic of this particular thread), it is not relevant here (I'm assuming you're not looking for a Windows solution for what is already available from Access). Let me know if this is a discussion you'd like to continue separately and I'll split this into a new thread for you. It is interesting after all.

[Sedrick]

Sorry for the delay. Yes if you could break that into another thread, I'd be interested in discussing it. Thank you for pointing out the solution to the current problem - /cmd option from the command line. That should work perfect!

This other discussion on application automation seems quite valuable to me for future applications.

Thanks!

[NeoPa]

All done :-)

[SoundGuy]

If you're still interested in an example of SaveSetting() and GetSetting(), I spent an hour or so today figuring out how it works and then putting it to use. I use it to communicate one piece of data between two databases, both of which are open at the same time on the same computer but which cannot (at the moment) be somehow combined into one.

In one db I have a form that presents data that is looked up based on a production order and a button click (no rocket science). The lookup and presentation of the most recent data is accomplished during the FormCurrent event. After all the fields have been filled by query results, one string is stored in the registry with this statement:

SaveSetting "DevLabel", "Text", "LastDevID", txtTmpID.Value

The Access VBA helps says of this function:

SaveSetting appname, section, key, setting

I discovered that "appname" can be any string as can "section" and "key" with "setting" being the string you want to store in the registry for later use. They just have to be the same as are used in the GetSetting function.

The user then alt-tabs over to the next database window and clicks a button which gets the data from the registry, puts it in a text field and then triggers a click event to perform the next step in the process:

Private Sub btnGetLatestID_Click()
    Dim txtID As String
 
    txtID = GetSetting("DevLabel", "Text", "LastDevID", "")
    If txtID = Null Or txtID = "" Then
        MsgBox "No device ID passed from DB, scan traveler sheet"
        Me.txtIdentnummer.SetFocus
    Else
        Me.txtIdentnummer.Value = txtID
        Me.btn_LookupDevID.SetFocus   ' probably not required
        Call btn_LookupDevID_Click
        DeleteSetting "DevLabel", "Text", "LastDevID"
    End If
End Sub

The GetSetting returns the string from the registry or an empty string (default) if there is no entry. After using the string I delete the entry so it can't accidentally be used again.

This probably beginner stuff but it made a huge simplification in our manufacturing process possible. I would never have known about it if I hadn't googled across this discussion.

Thanks,

--SG

[NeoPa]

Thanks to you too, for posting what you managed to get working.

PS. Bold tags work, but don't highlight well, when used within a CODE tag block, so I'll change them to italics for you.

PPS Italics wasn't too clear either so I used underscores instead.

[Sedrick]

SoundGuy,

Glad to hear ADezii's suggestion helped in your application!

Thanks NeoPa and ADezii for all the input to my questions. Sorry haven't gotten back to this sooner.

Was looking at the GetObject function but have not had time to test it out yet. Seems like it might read standard objects but not classes created with VBA. I'm thinking about trying it with the CurrentDb.Properties members to see if it would access them.

I'm also thinking it might be possible to read data from a field on a form in the calling database from the called database. I wonder, since the form class is not created by VBA if it would allow access to the Form's Class modules. I've done some work recently involving making Subs and Variables Public in a form class module and accessing them from other forms.

Will be good to take a closer look when I get some time. I think it will come in handy in the future.