Skip to main content

Navigation Model

Source: homersys library (w_sfpi_frame, w_system_tree_menu, w_system_menu, d_system_menu_datawindow, m_sys_frame, u_member_search, f_useraccess), inventory.json (window opens_windows links), HOMER.INI.

Overall shell

HOMER is a multiple-document-interface (MDI) application. A single frame window (homersys/w_sfpi_frame, comment: "Frame window for the SFPI Homer application") hosts every business screen as a sheet. The frame provides:

  • A status bar showing the logged-in user, the connected database, the active window's internal name (win_id), and a clock refreshed on a timer (w_sfpi_frame open/activate events; HOMER.INI [SETTINGS] timerinterval, timerformat).
  • The connection banner in the microhelp line: "User <id> connected to: <database>" (w_sfpi_frame line ~128).
  • Status-bar indicators for member notes (none / notes found / VIP notes found) updated by the active sheet (w_sfpi_frame wf_notes_found, wf_no_notes, wf_vip_notes_found).
  • The main menu bar m_sys_frame, whose items are security-filtered at frame open by gnv_menu_security.of_applymenusecurity(this.menuid) — see Security Model (w_sfpi_frame line ~215).

Primary navigator: the tree menu

At frame open, if the per-user INI setting [SETTINGS] sys_menu is TRUE (default TRUE; the workstation HOMER.INI ships sys_menu=tRUE), the frame opens the navigator sheet w_system_tree_menu ("System menu - tree structure") (w_sfpi_frame line ~219).

Mechanics (homersys/w_system_tree_menu):

  • The tree is built from the frame menu itself: ue_load walks the m_functions branch of m_sys_frame and creates one tree node per menu item, storing the live menu object in the node's data (str_menu_item with menu_object, program, enabled, level).
  • Selecting a leaf and launching it calls wf_launchprogram, which simply triggers the underlying menu item's Clicked event — so the tree and the menu bar are two views of one function catalog. If the menu item was disabled by menu security, the user gets "Access Denied - You do not have the proper security authorization to run this program."
  • Per-user personalization is stored as rows in a user-INI table (datastore ids_user_ini, section MENU): a Home position (wf_sethome, key HOME) and a Favorites list shown in a listview (wf_setfavorite / wf_loadfavorites, keys FAVORITEnn); favorites accept only program leaves, not folders ("You can only add programs as favorites").
  • Node icons come from workstation image files (C:\homer\folder.gif, menu_item.giftv_system_menu.picturename[]).

The frame can also (re)open the tree menu on demand: w_sfpi_frame event ue_system_menu executes OpenSheetWithParm(..., "w_system_tree_menu", ...) (line ~41), and m_sys_frame line ~1887 opens it from the menu bar.

Secondary navigator: the data-driven icon menu

homersys/w_system_menu ("Window providing navigator 'buttons' for all the functions for Homer") is an earlier, table-driven navigator that still exists in the code:

  • Its DataWindow d_system_menu_datawindow retrieves from the system_menu table: SELECT :picture_path||picture_name, sys_menu_option, window_to_open, display_order, menu, parameter FROM system_menu WHERE menu = :menu_name ORDER BY display_order — a self-referencing hierarchy where each row belongs to a named menu level and either opens a window or names a child menu level. Rows render as a grid of up to 10 picture buttons per band.
  • The root level is retrieved with argument "Main" (pfc_postopen, is_retrieveargs = "Main"); the picture path prefix comes from the application manager (gnv_app.of_get_pict_path) (pfc_retrieve).
  • Clicking/double-clicking a tile inspects window_to_open (dw_menu_selection::doubleclicked):
    • prefix w — a sheet window: access is verified with f_useraccess(ls_obj) (homersys/f_useraccess.srf); on success the sheet is opened with OpenSheet, or OpenSheetWithParm when the row's parameter column is non-empty, so the system_menu table can pre-parameterize a target screen. On failure: "Invalid Request - You do not currently have access...".
    • prefix r — a response (modal) window: the prefix is rewritten to w and the window is opened with Open after the same f_useraccess check.
    • prefix x (or shift-click) — navigate back one menu level (ue_return_level, which looks up the parent level in system_menu).
    • anything else — treated as a child menu name: the breadcrumb title (st_1.text) is extended with " - <option>" and the DataWindow is re-retrieved for that level; the Exit option closes the application.
  • Window-level security is also applied on open via gnv_app.inv_security.of_SetSecurity(This) (open event) — see Security Model.
  • The system_menu table has its own security maintenance screen (app_sec/w_system_menu_security).

Member-search-centric entry points

Most day-to-day work starts from a member (subscriber/patient) lookup rather than from a record browser:

  • homersys/u_member_search is a reusable search panel (criteria DataWindow d_member_search_criteria, results d_member_search). Its ue_postconstructor registers the search fields with a shared member-search service (inv_MemberSearch.of_Register(... 'ssn', 'last_name', 'first_name', 'middle_name', 'member_id', 'group_id', 'group_name', 'patient_syskey', 'sub_member_sys_key', ...)), and ue_search/ue_clear drive it.
  • homersys/w_member_search ("Generic Member Search window") wraps the panel in a modal response window so any screen can prompt for a member.
  • The panel is embedded directly in 11 windows across business areas, e.g. claims/w_eob_selection, claims/w_audit_members_selection, claims/w_claims_member_accum, cob/w_cob_select, enroll/w_hipaa_dead_file, enroll/w_enroll_custom_term_add_members, enroll/w_enroll_hipaa_add_members, stoploss/w_sl_spec_clm_listing, stoploss/w_sl_variable_clm_listing, clmrpt/w_rpt_member_accum_rulemax (grep of u_member_search across _re/src).
  • Menu-bar handlers in m_sys_frame implement the "select first, then open" pattern: they open a selection sheet with parameters, e.g. w_enroll_member_selection, w_group_member_select, w_group_hb1_member_select, w_quick_enroll_main, w_homer_id_req, w_drugplan_member_maint (all via OpenSheetWithParm, m_sys_frame lines ~3976-4293).
  • A user preference directtomember (HOMER.INI [APP PREFERENCES], maintained by system/u_app_preference and enroll/w_enroll_member_selection) makes member selection jump straight to the member instead of an intermediate list.

Window-to-window flow highlights

From analysis/inventory.json (opens_windows links, 546 windows):

  • Hub screens that fan out: um_ur/w_um_authorization opens 10 other windows; um_cm/w_um_case_management and um_ur/w_um_pre_certification open 7 each; enroll/w_group_hb1_member_select and enroll/w_group_member_select open 6 each; enroll/w_enrollment_maintenance, provider/w_provider_maintenance, um_ur/w_um_admission_notification, um_ur/w_um_referral open 5 each; claims/w_claim_editor and enroll/w_quick_enroll_main open 4 each.
  • Shared picker/response windows reached from many places: w_group_response_selection (opened by 12 windows), w_provider_vendor_select and w_pricing_plan_maintenance_single (6 each), w_um_diagnosis_cd_select, w_um_case_patient_select, w_um_procedure_cd_select (5-6 each), w_member_select_by_last_name, w_enrollment_maintenance, w_enrollment_cob_maint (3 each).

The pattern is consistent: maintenance/worklist sheets open small modal selection windows (group, provider, member, diagnosis/procedure code) and receive the chosen key back, rather than embedding lookups inline.

Requirements

  • NAV-1 The application shall present all business functions inside a single main window (MDI shell) with a status area showing the logged-in user, the connected environment, and the active screen's identity (homersys/w_sfpi_frame).
  • NAV-2 The primary navigator shall present the security-filtered function catalog as a hierarchical tree; launching a leaf shall invoke exactly the same action as the corresponding menu-bar item, and security-disabled items shall refuse to launch with an explanatory message (homersys/w_system_tree_menu::wf_launchprogram).
  • NAV-3 Users shall be able to personalize navigation with a saved "home" position and a favorites list of function shortcuts, persisted per user in the database, restored at next logon (homersys/w_system_tree_menu::wf_sethome/wf_setfavorite/wf_loadfavorites).
  • NAV-4 The system shall support a data-driven menu hierarchy stored in a database table (system_menu) where each entry defines its parent level, display order, display caption, icon, target screen, and an optional launch parameter passed to the target (homersys/d_system_menu_datawindow, w_system_menu::doubleclickedOpenSheetWithParm).
  • NAV-5 Every navigation-initiated screen open shall be preceded by a per-user access check on the target screen name, with a uniform denial message directing the user to the system administrator (homersys/w_system_menuf_useraccess; see Security Model).
  • NAV-6 Whether the navigator opens automatically at logon shall be a per-user preference (sys_menu setting; homersys/w_sfpi_frame line ~219).
  • NAV-7 A reusable member search component (criteria: SSN, name, member ID, group) shall be available both embedded in business screens and as a modal prompt, returning the selected member's keys to the caller (homersys/u_member_search, homersys/w_member_search).
  • NAV-8 Business screens shall obtain foreign keys (group, member, provider, diagnosis/procedure code, vendor) through shared modal selection windows rather than free-text entry (inventory.json opens_windows: w_group_response_selection reached from 12 windows, etc.).
  • NAV-9 A per-user "direct to member" preference shall let member selection bypass intermediate result lists (system/u_app_preference, HOMER.INI [APP PREFERENCES] directtomember).

Open questions

  • The system_menu table's actual contents (the live menu hierarchy and which rows carry parameter values) are data, not code, and were not available to this analysis; the migrated navigation catalog must be extracted from the production table.
  • Both navigators coexist. w_system_tree_menu is what the frame opens at logon; w_system_menu (icon grid) appears to be the older generation (much of its handler code is commented out) but is still referenced by app_sec/w_system_menu_security. Confirm with users whether the icon-grid navigator is still reachable/used before carrying it forward.
  • Navigator icons and pictures are loose files on each workstation (C:\homer\*.gif, picture_path prefix from the application manager) — a deployment concern, not a data concern, in the target platform.