@pcinfogmach מסקרנות שאלתי את GPT, ומעניין אותי האם הוא מבלבל תשכל, או שהוא מדבר לעניין:

כן. ועכשיו, אחרי שבדקתי את הקוד של הפרויקט, יש דרך טובה לעשות את זה, ואפילו הייתי ממליץ עליה יותר מאשר ליצור vesto://.

התוסף הוא VSTO Add-in אמיתי ל-Word, עם ThisAddIn.cs, Ribbon XML ומנהל Task Panes. כלומר, אנחנו יכולים להוסיף לו נקודת כניסה חיצונית שתאפשר למאקרו VBA להפעיל פעולה ספציפית.

מה שאתה רוצה לעשות

המטרה שלך היא למעשה:

קיצור מקשים של Word → מאקרו VBA → הפעלת פקודה של VESTO

לדוגמה:

Ctrl+Alt+V
      ↓
SearchInVesto()
      ↓
VESTO מקבל את הטקסט המסומן
      ↓
נפתח/מופעל כלי החיפוש של VESTO

וזה בהחלט אפשרי.

יש שתי דרכים

1. URI Protocol — vesto://

אפשר להוסיף ל-VESTO פרוטוקול Windows משל עצמו, למשל:

vesto://search/שלום

ואז המאקרו שלך יהיה כמעט זהה ל־SearchInZayit:

Sub SearchInVesto()

    Dim SearchText As String
    Dim URL As String

    SearchText = Selection.Range.Text
    SearchText = Replace(SearchText, " ", "%20")

    URL = "vesto://search/" & SearchText

    CreateObject("WScript.Shell").Run URL

End Sub

אבל כאן יש חיסרון: צריך להעביר את הבקשה דרך Windows ולהכניס מנגנון URI לתוסף.

2. דרך שאני חושב שעדיפה במקרה שלך — API קטן בין VBA ל-VESTO

מכיוון ש-VESTO כבר רץ בתוך Word, אפשר להוסיף לו פקודה שניתנת לקריאה מבחוץ, למשל דרך:

• WM_COPYDATA
• Named Pipe
• COM
• או אפילו מנגנון פשוט יותר.

ואז המאקרו יכול לומר:

"VESTO, קח את הטקסט הזה ובצע את הפקודה X."

זה מאפשר בעתיד לא רק חיפוש, אלא למשל:

VESTO.Search("טקסט")
VESTO.OpenKitveiHakodesh()
VESTO.OpenRegex()
VESTO.Format()

וכדומה.

ויש עוד אפשרות מעניינת במיוחד

מכיוון שהתוסף כבר משתמש ב־Ribbon XML ומחלק את הפעולות לכפתורים, ייתכן שאפשר לא להוסיף שום תקשורת חיצונית בכלל.

אפשר להוסיף ל-VESTO Ribbon command ייעודי, ואז לבדוק האם Word יכול להפעיל אותו באמצעות:

Application.CommandBars.ExecuteMso "שם-הפקודה"

אם זה יעבוד, זה יהיה הפתרון הכי נקי:

Sub VestoSearch()
    Application.CommandBars.ExecuteMso "VestoSearch"
End Sub

ואז אתה נותן למאקרו קיצור מקשים דרך Word, בדיוק כפי שרצית.

לכן הייתי בודק קודם את האפשרות השלישית, ורק אם היא לא מתאימה — בונה vesto://.

היות שיש לנו את קוד המקור של VESTO, אני יכול לבדוק את KeliKodeshRibbon.cs ואת KeliKodeshRibbon.xml ולראות איך הפקודות של התוסף מוגדרות כרגע, ואז לומר לך אם אפשר להפעיל אותן ישירות מ-VBA ואם לא — מה השינוי הקטן ביותר בקוד שייתן לך את היכולת הזאת.

כן. בדקתי את המבנה האמיתי של VESTO בקוד, ויש כאן חדשות טובות: לא צריך להוסיף vesto:// בכלל.

במקרה הזה הייתי עושה מנגנון פשוט ונקי יותר:

קיצור מקשים של Word → מאקרו VBA → פקודת VSTO חשופה → VESTO מפעיל את החיפוש.

כבר עכשיו ב־VESTO יש contextMenu_Click, והוא יודע לקחת את הטקסט המסומן מתוך Word ולהעביר אותו ל־AppViewer.SearchFromHost(text, target).

הייתי מרחיב בדיוק את המנגנון הזה.

1. שינוי ב־KeliKodeshRibbon.cs

בתוך המחלקה KeliKodeshRibbon, הוסף את הפונקציה הבאה:

/// <summary>
/// נקודת כניסה להפעלת חיפוש בכתבי הקודש מתוך VBA/Automation.
/// לוקח את הטקסט המסומן כרגע ב-Word ומפעיל חיפוש FTS.
/// </summary>
public void SearchKitveiHakodeshFromVba()
{
    try
    {
        string text = Globals.ThisAddIn.Application.Selection?.Text;

        if (string.IsNullOrWhiteSpace(text))
            return;

        var appViewer = ShowKitveiHakodesh();

        appViewer?.SearchFromHost(text, "fts");
    }
    catch (Exception ex)
    {
        MessageBox.Show(
            ex.Message,
            "חיפוש בכתבי הקודש",
            MessageBoxButtons.OK,
            MessageBoxIcon.Error);
    }
}

זה למעשה ממחזר את המנגנון שכבר קיים בתוסף:

string text = Globals.ThisAddIn.Application.Selection?.Text;
...
var appViewer = ShowKitveiHakodesh();
appViewer?.SearchFromHost(text, target);

2. אבל יש נקודה חשובה

VBA לא יכול פשוט לעשות:

KeliKodeshRibbon.SearchKitveiHakodeshFromVba

כי אובייקט ה־Ribbon אינו חשוף ל־VBA בצורה כזאת באופן אוטומטי.

לכן אני ממליץ לעשות COM Automation קטן.

ב־VSTO יש לנו כבר ThisAddIn.cs, שהוא נקודת הכניסה של התוסף.

במקום לחשוף את ה־Ribbon עצמו, נחשוף אובייקט קטן בשם למשל:

KleiKodeshApi

עם פעולה:

SearchKitveiHakodesh()

ואז VBA יוכל לדבר איתו.

3. ה־API

צור קובץ חדש:

KleiKodeshVsto/Automation/KleiKodeshApi.cs

עם:

using System;
using System.Runtime.InteropServices;

namespace KleiKodesh.Automation
{
    [ComVisible(true)]
    [Guid("7D7E6F3B-8B7C-4D89-9E72-1A3C4F8B52A1")]
    [InterfaceType(ComInterfaceType.InterfaceIsDual)]
    public interface IKleiKodeshApi
    {
        void SearchKitveiHakodesh();
    }

    [ComVisible(true)]
    [Guid("A3B8D6F1-2E44-4A7D-9C91-6B2E8F4D1735")]
    [ClassInterface(ClassInterfaceType.None)]
    public class KleiKodeshApi : IKleiKodeshApi
    {
        public void SearchKitveiHakodesh()
        {
            Globals.ThisAddIn.SearchKitveiHakodesh();
        }
    }
}

ואז ב־ThisAddIn.cs נוסיף:

public void SearchKitveiHakodesh()
{
    try
    {
        string text = Application.Selection?.Text;

        if (string.IsNullOrWhiteSpace(text))
            return;

        var appViewer = Ribbon?.ShowKitveiHakodeshForAutomation();

        appViewer?.SearchFromHost(text, "fts");
    }
    catch (Exception ex)
    {
        System.Windows.Forms.MessageBox.Show(
            ex.Message,
            "חיפוש בכתבי הקודש",
            System.Windows.Forms.MessageBoxButtons.OK,
            System.Windows.Forms.MessageBoxIcon.Error);
    }
}

אבל כאן הייתי עושה שינוי קטן נוסף בארכיטקטורה, כדי לא להפוך את Ribbon לתלות של ה־API.

כלומר, עדיף שהפעולה עצמה תהיה ב־ThisAddIn, ותשתמש ישירות ב־TaskPaneManager.

4. הגרסה שאני ממליץ עליה בפועל

ב־ThisAddIn.cs:

public void SearchKitveiHakodesh()
{
    try
    {
        string text = Application.Selection?.Text;

        if (string.IsNullOrWhiteSpace(text))
            return;

        var pane = TaskPaneManager.Show(
            () => new KitveiHakodeshLib.AppViewer
            {
                ShowPopOutButton = true
            },
            "כתבי הקודש",
            610,
            popOutBehavior: true);

        var appViewer = pane?.Control as KitveiHakodeshLib.AppViewer;

        appViewer?.SearchFromHost(text, "fts");
    }
    catch (Exception ex)
    {
        System.Windows.Forms.MessageBox.Show(
            ex.Message,
            "חיפוש בכתבי הקודש",
            System.Windows.Forms.MessageBoxButtons.OK,
            System.Windows.Forms.MessageBoxIcon.Error);
    }
}

זה משתמש באותו TaskPaneManager.Show שבו התוסף משתמש כבר עכשיו כדי ליצור/למחזר את חלונית כתבי הקודש.

5. ה־VBA

ואז המאקרו יכול להיות:

Sub SearchInVesto()

    Dim Vesto As Object

    Set Vesto = CreateObject("KleiKodesh.Automation.KleiKodeshApi")

    Vesto.SearchKitveiHakodesh

End Sub

ואז:

סמן טקסט → קיצור מקשים → המאקרו → VESTO → חיפוש.

אבל יש לי הצעה אפילו טובה יותר

מכיוון שהמטרה שלך היא קיצור מקשים, הייתי בונה את ה־API מראש בצורה שתאפשר לך כמה פקודות:

public interface IKleiKodeshApi
{
    void SearchKitveiHakodesh();
    void SearchCatalog();
    void OpenKitveiHakodesh();
}

ואז ב־VBA:

Sub VestoSearch()
    Dim Vesto As Object
    Set Vesto = CreateObject("KleiKodesh.Automation.KleiKodeshApi")
    Vesto.SearchKitveiHakodesh
End Sub

ובהמשך:

Sub VestoCatalogSearch()
    Dim Vesto As Object
    Set Vesto = CreateObject("KleiKodesh.Automation.KleiKodeshApi")
    Vesto.SearchCatalog
End Sub

כך תוכל להקצות קיצור מקשים נפרד לכל פעולה של VESTO, למרות ש-Word עצמו לא מאפשר לך להגדיר קיצור ישירות לכפתורי התוסף.

דבר אחד חשוב לפני שאתה משנה את הקוד

ה־CreateObject("KleiKodesh.Automation.KleiKodeshApi") דורש שה־COM class יירשם ב־Windows. ב־VSTO זה לא תמיד קורה אוטומטית רק בגלל [ComVisible(true)].

לכן לא הייתי מכניס עדיין את קוד ה־COM הזה לפרויקט ומקמפל. כדאי קודם לבדוק את ThisAddIn.cs ואת קובץ הפרויקט .csproj, ובעיקר איך המתקין של KleiKodesh מתקין ורושם את ה־VSTO. המתקין נמצא בפרויקט Build/Installer, וה־README מאשר שזה המנגנון שמתקין את תוסף ה־VSTO.

נראה לי שהיום, הבקיאים ביותר באקסל זה AI, כי רק הם מכירים את רוב הפונקציות והנוסחאות.