GenSmarts Goto Interface

GenSmarts Version 2 will now utilize a formal Windows messaging interface for the purpose of transferring a user to a specific ancestor in running genealogical record keeping application (RKA). An informal way of doing this in GenSmarts Version 1 continues to be functional in Windows XP (and older), though the formal interface is required for this "go to person" functionality under MS Vista. Users attempting the "go to" under Vista will be informed to contact their RKA vendor to request support of this new interface. The new formal interface, if available, will be utilized on all platforms in preference to the older informal interface method. Vista's new security rules prevent an application from passing keystrokes to another application, which is how the older informal interface method worked... so the older interface method is not functional on Vista.

The user experience is quite nice with this interaction between GenSmarts and the RKA, especially if the user has enough screen real estate to allow both applications to be visible at once. Whereas the old informal interface required the user to execute a keystroke or two, the new interface approach is fully automated. A typical usage scenario would be where a user in GenSmarts is inspired by some information to want to change their data in the RKA, so invokes the "goto person" function key of the RKA while in GenSmarts (e.g. CTRL-I if it's a TMG user, CTRL-G if it's a Legacy user, F2 for FTM, CTRL-F for RootsMagic, etc.). GenSmarts passes the go to request over to the RKA, along with the internal record id of the person in question. What the user sees after pressing the function key is the focus switch to the RKA and that ancestor brought forward for editing.

Incidently, nothing about this interface is proprietary to GenSmarts, so once the RKA implements it, other applications could utilize it also, not just GenSmarts.

To implement the formal Windows messaging interface, the RKA needs to implement a standard windows message routine to receive the message along with a 4 byte integer internal record id number, determine if the current user interface state is appropriate for switching to a view of this person, and then either performing the appropriate UI shift if appropriate. In the case where a UI shift to a person view is not appropriate, a message to that affect would be nice, but not required - there may be UI states, such as a file save dialog or a progress dialog, where a message would not be possible/advisable.

The interface driver below should be useful for RKA developers - it allows invoking of the interface exactly as GenSmarts will do it, with the exception that the RKA developer may plug in the message number and parameters as needed.

The RKA will need to contact GenSmarts ( support@GenSmarts.com ) with the following information when the interface is available:

a) the message number expected by RKA for this function (e.g. WM_USER)

b) confirmation that the internal record id number is expected to be passed in LPARAM

c) the version number of the RKA required for support of this interface, so GenSmarts can inform the user attempting to use this function of the necessary upgrade

Here is a download link to the interface driver program for RKA developers:

https://s3-us-west-2.amazonaws.com/gensmarts.com/download/SendMessageTest.exe

Here is sample code for implementing the interface. It's in Delphi Pascal, but other languages will be similar:

const

{WM_USER is the start of custom defined windows message numbers}

WMGOTOPERSON = WMUSER + 1; // change the +1 to be more than 1 if you already have some custom messages

type

TYourMasterForm = class (TForm)

..........

private

procedure WndProc(var Msg : TMessage); override; // override the default message handler

....

public

.........

protected

..........

end;

...............

implementation

.............

procedure TMasterForm.WndProc(var Msg : TMessage);

begin

case Msg.Msg of

WM_GOTOPERSON:

try

self.DisplayPersonWithId(Msg.lParam); // or whatever routine you have to do the job (Msg.lParam is an integer with the id#)

except

{if anything goes wrong, just ignore it}

end;

end;

inherited; // now let the default routine handle this and any other messages

{note that every message will flow through here (e.g. every mouse click, repaint, etc.)}

end;

...........

end.