Don,
I have been fighting with making the change tracking work with all possible Scintilla's and banging my head against a wall for days thinking my filtering was incorrect, and each time I thought I had it corrected it would go bad again.
Is there a reason why the check on this is _pEditView == &_mainEditView?
It makes updating of the currHView incorrect whenever another editView is active. ( ie: Find/Replace )
Do you think this should count as a bug? If so I'll fill out a ticket, if not I'll figure out something else to track the current view. For now I'll just compare to hMainView and hSecondView instead of hCurrView and hAltView.
Thanks,
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That should make updating the current focused view and alternate view easier and more accurate...
Now the following should always return the correct handle:
> Is there a reason why the check on this is _pEditView == &_mainEditView?
> It makes updating of the currHView incorrect whenever another editView is
> active. ( ie: Find/Replace )
Which code are you talking about? (# of file, # of line...)
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry about that... from rev 437 Notepad_plus.cpp line 7724 ( NPPM_GETCURRENTSCINTILLA ).
I imagine that there aren't any uses for having it return an incorrect SUB_VIEW response when the actual last focused view was MAIN_VIEW prior to _pEditView getting point to the invisible view for a Find/Replace or some such.
Perhaps: going off of the internal NPPM_INTERNAL_ISFOCUSEDTAB?
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's the thing though, it doesn't match! It may be within bounds of MAIN_VIEW and SUB_VIEW but the returned view is not the view one would expect to have returned.
If the current Scintilla is MAIN_VIEW 0 and a plugin is using that as a current view handle, and then the current Scintilla is switched to the invisible view and a new call is made to GETCURRENTSCINTILLA the returned value is SUB_VIEW, which is incorrect. I'd expect to still see MAIN_VIEW returned, wouldn't you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, _invisibleEditView could be pointed by _pEditView.
It is going to be changed to :
//----------------------------------------//
case NPPM_GETCURRENTSCINTILLA :
{
if (_pEditView == &_mainEditView)
*((int *)lParam) = MAIN_VIEW;
else if (_pEditView == &_subEditView)
*((int *)lParam) = SUB_VIEW;
else
*((int *)lParam) = -1;
return TRUE;
}
//----------------------------------------//
currentEdit indicates the current Scintilla view : 0 is the main Scintilla view 1 is the second Scintilla view, else -1 (not main view nor sub view).
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What a head ache!
Don,
I have been fighting with making the change tracking work with all possible Scintilla's and banging my head against a wall for days thinking my filtering was incorrect, and each time I thought I had it corrected it would go bad again.
Is there a reason why the check on this is _pEditView == &_mainEditView?
It makes updating of the currHView incorrect whenever another editView is active. ( ie: Find/Replace )
Do you think this should count as a bug? If so I'll fill out a ticket, if not I'll figure out something else to track the current view. For now I'll just compare to hMainView and hSecondView instead of hCurrView and hAltView.
Thanks,
almostautomated
Excellent, thank you.
That should make updating the current focused view and alternate view easier and more accurate...
Now the following should always return the correct handle:
HWND hMainView() { return NppData._scintillaMainHandle; }
HWND hSecondView { return NppData._scintillaSecondHandle; }
HWND getHViewByInt(int view) { return ( view == MAIN_VIEW ) ? ( hMainView() ) : ( hSecondView() ); }
HWND hCurrView()
{
static HWND hPrevCurrView;
int tmpView = ::SendMessage( hNpp(), NPPM_GETCURRENTSCINTILLA, 0, 0);
if ( tmpView != -1 ) {
hPrevCurrView = ( getHViewByInt( tmpView ) );
}
return hPrevCurrView;
}
HWND hAltView() { return ( hCurrView() == hMainView() ) ? ( hMainView() ) : ( hSecondView() );
Actually, the previously posted code needed an edit, here's the modified routine in case anyone else had issues:
// Update handle pointer to the currently active view.
HWND updateCurrViewHandle()
{
static HWND hPrevCurrView;
_bRefreshCurrViewH = false;
int currentEdit;
::SendMessage(_hNpp, NPPM_GETCURRENTSCINTILLA, 0, (LPARAM)¤tEdit);
if ( currentEdit != -1 ) {
hPrevCurrView = ( currentEdit == 0 ) ? ( _hScintillaMain ): ( _hScintillaSecond );
}
return ( hPrevCurrView );
}
HWND hCurrView()
{
if ( _bRefreshCurrViewH || !_isReady ) {
_hCurrView = updateCurrViewHandle();
}
return _hCurrView;
}
HWND hAltView() { return ( ( hCurrView() == _hScintillaMain ) ? ( _hScintillaSecond ) : ( _hScintillaMain ) ); }
FYI :
Committed in svn.
Don
> Is there a reason why the check on this is _pEditView == &_mainEditView?
> It makes updating of the currHView incorrect whenever another editView is
> active. ( ie: Find/Replace )
Which code are you talking about? (# of file, # of line...)
Don
Sorry about that... from rev 437 Notepad_plus.cpp line 7724 ( NPPM_GETCURRENTSCINTILLA ).
I imagine that there aren't any uses for having it return an incorrect SUB_VIEW response when the actual last focused view was MAIN_VIEW prior to _pEditView getting point to the invisible view for a Find/Replace or some such.
Perhaps: going off of the internal NPPM_INTERNAL_ISFOCUSEDTAB?
almostautomated
Officially there are only 2 scintilla views are accessible by plugins.
Here's the document on line :
//----------------------------------------------------------------------------------//
NPPM_GETCURRENTSCINTILLA
wParam : 0
lParam : [out] int * currentEdit
currentEdit indicates the current Scintilla view : 0 is the main Scintilla view 1 is the second Scintilla view.
(See :
http://notepad-plus.sourceforge.net/uk/plugins-HOWTO.php\)
//----------------------------------------------------------------------------------//
I don't see the problem since the return value matches the following definitions :
#define MAIN_VIEW 0
#define SUB_VIEW 1
Don
That's the thing though, it doesn't match! It may be within bounds of MAIN_VIEW and SUB_VIEW but the returned view is not the view one would expect to have returned.
If the current Scintilla is MAIN_VIEW 0 and a plugin is using that as a current view handle, and then the current Scintilla is switched to the invisible view and a new call is made to GETCURRENTSCINTILLA the returned value is SUB_VIEW, which is incorrect. I'd expect to still see MAIN_VIEW returned, wouldn't you?
Indeed, _invisibleEditView could be pointed by _pEditView.
It is going to be changed to :
//----------------------------------------//
case NPPM_GETCURRENTSCINTILLA :
{
if (_pEditView == &_mainEditView)
*((int *)lParam) = MAIN_VIEW;
else if (_pEditView == &_subEditView)
*((int *)lParam) = SUB_VIEW;
else
*((int *)lParam) = -1;
return TRUE;
}
//----------------------------------------//
currentEdit indicates the current Scintilla view : 0 is the main Scintilla view 1 is the second Scintilla view, else -1 (not main view nor sub view).
Don