#53 NppExec ini files stored in wrong folder

open
nobody
NppExec (14)
3
2011-07-29
2008-02-09
Jens Lorenz
No

NppExec stores his ini file directly in Notepad++\plugins\config folder whereas I have Notepad++ installed with installer (user profile on windows is available). Please change this behaviour and use the NPPM_GETPLUGINSCONFIGDIR to get the correct location.

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Is it so important? Actually, I don't like the idea of separated options for each user on one's PC. If you have Notepad++ on your PC and you use the NppExec plugin, would you like absolutely different options and scripts in NppExec when you enter the system as another user? Personally I have to duplicate all my settings in such cases, and I don't like it.
    Here is the full list of files created and used by the NppExec plugin:
    - NppExec.ini (general options)
    - npec_cmdhistory.txt (console command history)
    - npes_saved.txt (saved scripts)
    - npes_temp.txt (temporary script)
    Does it make sense to store separate copies of all these files for each user? IMHO, no.

    DV.

     
  • Nobody/Anonymous

    Logged In: NO

    My issue was yesterday, that I deleted the config/plugins folder in Notepad++ because I would like to delete doublicated files and in addition I thought it wasn't in use. So all my config files of NppExec were gone :(.

    Maybe is it not your personal preference, but every plugin should store his options in the Notpad++ specific config folder to have a clean installation. For example currently we have many plugins and all of these plugins have his own config installation location:

    - NppExec don't uses the user profile folder of windows
    - TextFx stores in Notepad++\plugins directly (I think we have change this also)
    - QuickText stores the configuration direct in the Notepad++ folder !

    We have to clean that!

    Jens

     
  • Nobody/Anonymous

    Logged In: NO

    NppExec initializes some of its parameters BEFORE its function setInfo(NppData) is called by Notepad++. Thus, when NppExec reads its options, it can't use NPPM_GETPLUGINSCONFIGDIR because the Notepad++'s window handle (nppData._nppHandle) is unknown at that moment.

     
  • Jens Lorenz

    Jens Lorenz - 2008-02-11

    Logged In: YES
    user_id=1332303
    Originator: YES

    I don't know where to problem is. All my application needs the settings after initialization of Notepad++, because before it makes no sense to have them before setInfo (e.g. INI files). The other information, like your text files, IMO are only needed when the user requested for it. Maybe you should change your sequence a little bit to make it possible.

     
  • Nobody/Anonymous

    Logged In: NO

    When you want to create the plugin's menu dinamically, basing on the plugin's settings, you can do it only before Notepad++ calls the plugin's function getFuncsArray(int *). Do you want to say that setInfo(NppData) is always called before getFuncsArray(int *)? If yes, then the plugin's menu must be created not in the DllMain(), but right after setInfo(NppData) or inside getFuncsArray(int *) before it returns.

    DV.

     
  • Jens Lorenz

    Jens Lorenz - 2008-02-11

    Logged In: YES
    user_id=1332303
    Originator: YES

    For this porpuse I implemented an additional function. This is what is does:

    HMENU hMenu = ::GetMenu(nppData._nppHandle);
    ::ModifyMenu(hMenu, funcItem[2]._cmdID, MF_BYCOMMAND | MF_SEPARATOR, 0, 0);
    ::ModifyMenu(hMenu, funcItem[4]._cmdID, MF_BYCOMMAND | MF_SEPARATOR, 0, 0);

    Also possible is if you want to have only some items visible:
    ::DeleteMenu(hMenu, funcItem[2]._cmdID, MF_BYCOMMAND);

    Or to change the string just use:
    ::ModifyMenu(hMenu, funcItem[4]._cmdID, MF_BYCOMMAND | MF_STRING, 0, string);

    I think there are a lot of other posibilities.

    The modification I start in:
    extern "C" __declspec(dllexport) LRESULT messageProc(UINT Message, WPARAM wParam, LPARAM lParam)
    {
    if (Message == WM_CREATE)
    {
    initMenu();
    }
    return TRUE;
    }

     
  • Nobody/Anonymous

    Logged In: NO

    It does not allow to add new menu items. There can be situations when the plugin doesn't know how much menu items must it create, because these menu items are read from its ini-file.
    For example, you may want to create menu items for the scripts you use often. In such case, the information about these scripts can be read only from the ini-file and from the scripts-file, and it must be done BEFORE getFuncsArray(int *) is called by Notepad++.
    Another example: when you working with different encodings (codepages), you may not be interested in Chinese and Japanese encodings, but maybe you do. These settings must also be stored in some ini-file which also must be read BEFORE getFuncsArray(int *) is called by Notepad++.
    So, what's the way out?

    DV.

     
  • Jens Lorenz

    Jens Lorenz - 2008-02-13

    Logged In: YES
    user_id=1332303
    Originator: YES

    Provide only a maximum of elements in menu, we assume 10 possible scripts. Provide this in getFuncsArray[your normal size plus 10]. Now you are able to modify these elements in messageProc() with that functions that I provide you before. The unnecessary ones can be deleted.

    I think there is nothing complicated.

    Regarding the encodings. I didn't get you for what you do need the encodings. To provide it in console itself or in menu. If in menu, there is a plugin to called NativeLang that does this for you.

     
  • DV

    DV - 2008-02-13

    Logged In: YES
    user_id=1468738
    Originator: NO

    Regarding the encodings.
    At last I started to develop new version of ConvertExt plugin. It will work approximately to the following:
    - when the plugin is loaded, it enumerates all installed code-pages in your system
    - the it reads its config file and creates menu items only for those code-pages which have been selected by user previously
    - the created menu items will allow to view/encode a text file in different encodings
    So, how many menu items do you propose to create? 100? 1000? And then delete 980 menu items because user doesn't need them? From the other side, some users do work with different languages and different encodings, so they really may need 1000 menu items with different code-pages.
    As you can see, NPPM_GETPLUGINSCONFIGDIR creates problems and limitations here.
    Therefore I think that the plugin must read its options directly when it is loaded, thus the plugin's menu can be dynamic, depending on user settings.

    Regarding the NppExec plugin.
    The plugin has been designed assuming it initializes all its options when the plugin is loaded. If we want to change this behaviour now, it will require a lot of time unjustifiedly, without any practical advantage or improvements. IMHO, it will be a real waste of time. I like your another idea very much - creating of separate consoles for different tasks (e.g. tasks from another plugins) which is much more important object, IMHO. It also requires a lot of changes in the sources, but the result is worth.

     
  • Jens Lorenz

    Jens Lorenz - 2008-02-13

    Logged In: YES
    user_id=1332303
    Originator: YES

    Regarding your encoder:
    I would only include one menu item to select the language. If the user issues the menu item there will be another pop-up menu opened (sub-menu) created by your application. So Notepad++ is not the responsible application to create those menu entries when it's not need to used.

    Regarding the NppExec plugin:
    As you said, when you change this behaviour of storing configuration files, the user don't cares and it is a little bit work ( it couldn't be so much effort ! ). But IMO we should have a clean Notepad++. It is the idea to have it clean. Currently every developer of a plugin does is own rules. We should change this and we (SF Npp Plugins Side) should be a good example how to do it correctly.

    I will advice all developer to change this behaviour and Don is that one who supports me regarding this problem of inconsistence.

     
  • Nobody/Anonymous

    Logged In: NO

    Well, I'll think about it together with multiple consoles when v0.3 will be implemented. The plugin's internal structure and logic will be changed anyway.
    In v0.2 this behaviour will not be changed.

    Talking about submenus - this is a good idea except one thing: the submenu items will not have shortcut-keys because these menu items will be created after Notepad++ receives the plugin's funcItem array. Whereas these submenu items could have shortcut-keys if these items are created before.

    DV.

     
  • Alexander Iljin

    Alexander Iljin - 2011-07-29
    • assigned_to: alexiljin --> nobody
     

Log in to post a comment.