Determining if a marker is defined?

[almostautomated]

How would you go about determining if a marker has been defined via
the API?

Add each marker to a line; read it's type, and delete it, repeat; then
assume that marker id's with the mark as default circle are
undefined? Although, that is quite a bit of messing around...

With many Scintilla apps supporting plugins, it'd be nice to be able
to do a check similar to the check done in
Editor::SubstituteMarkerIfEmpty as a reply to something like
SCI_GETMARKERDEFINED.

How would you go about this?

Regards,
almostautomated

[almostautomated]

Well, that wont work since the SCI_MARKERGET doesn't tell the type,
just the marker...

[Neil Hodgson]

almostautomated:

> How would you go about determining if a marker has been defined via
> the API?

There is no API to determine if a marker has been defined.

> With many Scintilla apps supporting plugins, it'd be nice to be able
> to do a check similar to the check done in
> Editor::SubstituteMarkerIfEmpty as a reply to something like
> SCI_GETMARKERDEFINED.

SubstituteMarkerIfEmpty is there to allow old applications to work
despite changing behaviour in Scintilla where it started to
differentiate between more folder markers. I can't see a generic use
case here.

Neil

[almostautomated]

Thanks for the reply Neil,

You're absolutely right... I don't really see a generic use case here
either. Yet, being that there is the availability of markers, and
that not all of them would normally be available ( ie default folder
marks ) it would be beneficial to have at least a rudimentary method
of determining availability. I realize this may be more of a
container implementation issue and in that spirit here's a simple
function that will work from a plugin point of view...

Assuming you have a container that has multiple edit views and the
plugin has the handles to them, the plugin can be built against the
required libraries to allow creation of an Editor object and use
something along the following:

It looks better here: http://codepad.org/VL1dz5PT


// Returns -1 if there isn't enough space for markCount, else returns
the first markerID
// available with enough contiguous space to allow for markerCount.
int getFirstAvailableMarker(int markerCount)
{
// Since all markers are not available let NB_MAX_PLUGINMARKERS be
at least < 24.
if ( markerCount > NB_MAX_PLUGINMARKERS ) return ( false );

// Make the protected ViewStyle public to allow access to the marker
array.
class MarkerAccessor : public Editor {
public:
using Editor::vs;
};

MarkerAccessor* p_mView = reinterpret_cast<MarkerAccessor *>
(::GetWindowLongPtr( npp_plugin::hMainView(), 0));
MarkerAccessor* p_sView = reinterpret_cast<MarkerAccessor *>
(::GetWindowLongPtr( npp_plugin::hSecondView(), 0));

int firstAvail = -1;
int contiguous = 0;
LineMarker em; // Empty mark to test against.
LineMarker* mvm; // Main view mark to test.
LineMarker* svm; // Second view mark to test.

for ( int i = 0; i < NB_MAX_PLUGINMARKERS; i++ ) {
mvm = &p_mView->vs.markers[i];
svm = &p_sView->vs.markers[i];

if ( ( em.markType == mvm->markType ) && ( em.markType == svm-
>markType ) &&
( em.alpha == mvm->alpha ) && ( em.alpha == svm->alpha ) &&
( em.fore.allocated.AsLong() == mvm->fore.allocated.AsLong() ) &&
( em.fore.allocated.AsLong() == svm->fore.allocated.AsLong() ) &&
( em.back.allocated.AsLong() == mvm->back.allocated.AsLong() ) &&
( em.back.allocated.AsLong() == svm->back.allocated.AsLong() ) ) {

if ( contiguous == 0 ) firstAvail = i;
contiguous++;
}
else {
contiguous = 0;
}

if ( contiguous == markerCount ) break;
}

if ( contiguous != markerCount ) firstAvail = -1;

return ( firstAvail );
}

[almostautomated]

Corrected the return ( false ) to return ( -1 ) in the initial size
check.

http://codepad.org/fmo0gxwT#comment-64dfzT8E

[Neil Hodgson]

With only 32 markers and with many predefined, you really need to
know more about how the container uses markers. Most containers have a
small set of markers that have constant values but not all containers
set up all the markers at initialisation time, sometimes waiting for
debugging to start (for example) before defining the breakpoint and
instruction pointer markers. If application writers would like
Scintilla to do some simple mediation with plugins then that may be
possible but it doesn't seem very useful otherwise.

Neil

[almostautomated]

On Feb 23, 2:34 am, Neil Hodgson <nyamaton...@gmail.com> wrote:
>    With only 32 markers and with many predefined, you really need to
> know more about how the container uses markers.

Absolutely! This was one concern that Don (Notepad++) helped with by
defining the ranges in use by the container for both margins and
markers and what could be used by plugins. For instance margin 4 is
free for plugins as well as markers 0-15.


> ...but not all containers set up all the markers at initialisation time,

> sometimes waiting for debugging to start (for example) before defining the
> breakpoint and instruction pointer markers.

Exactly, which supports a case for getting the information regarding a
marker as well as being able to delete a marker ( to 'release' it for
use by others ).

> If application writers would like Scintilla to do some simple mediation with
> plugins then that may be possible but it doesn't seem very useful otherwise.
>
>    Neil

Well, I can't really reply to that since I'm not writing a Scintilla
based app; yet from a plugin writers point of view I'd sincerely like
to see something along the lines of:

SCI_MARKERGETAVAIL( int markerNumber )
This returns a currently unused marker number, if all markers are
currently in use -1 is returned.

SCI_MARKERSETAVAIL( int markerNumber )
This removes the current style definitions from marker markerNumber.

This may not be of much use, yet then again it may prove to be helpful
to those who would like to use markers and play nice with others at
the same time.

almostautomated

[almostautomated]

Actually I guess that first ones explanation wouldn't fit, it would
returns the first unused higher than the markerNum indicated. This
would ensure that markers that make use of the overlay would work as
expected.

int bottomMark = SendMessage( hWnd, SCI_MARKERGETAVAIL, 0, 0);
int nextHighestMark = SendMessage( hWnd, SCI_MARKERGETAVAIL,
bottomMark, 0);

[Neil Hodgson]

Probably simplest to define

fun int MarkerSymbol=2524(int markerNumber, )

and an invisible

val SC_MARK_AVAILABLE=28

Then the application can give away all the markers it wants by
setting them to SC_MARK_AVAILABLE.

The plugin can do any looping needed to find markers.

Neil

[almostautomated]

Yeah, that would work; at least a lot better than the route I've taken
with it. ;) That keeps control ( and responsibility ) more firmly in
the application instead of Scintilla.

Like you said before:

"...If application writers would like Scintilla to do some simple

mediation with plugins then that may be possible but it doesn't seem
very useful otherwise."

Maybe some will chime in...

[Neil Hodgson]

Me:

> fun int MarkerSymbol=2524(int markerNumber, )

Committed as SCI_MARKERSYMBOLDEFINED:
fun int MarkerSymbolDefined=2529(int markerNumber,)

Neil

[almostautomated]

Thank you Neil! No MarkerSymbolUndefine?

Here's what I have in a Notepad++ plugin that facilitates finding and
releasing markers for other plugins http://codepad.org/Rwknv7JF . As
you mentioned earlier in the thread, I left the looping up to the
plugin; so in a .lib created a couple of helper functions to check
both views to find the number of required markers and return them as
an array for the plugin to define as needed ( http://codepad.org/LZqo8Xj6
).

Thanks again,
almostautomated

[Neil Hodgson]

almostautomated:

> Thank you Neil!  No MarkerSymbolUndefine?

No as its more important to provide the atoms of functionality than
many convenience macros.

Neil

[almostautomated]

Fair enough.

Could the defualt marker type be SC_MARK_AVAILABLE so instead of a
container needing to 'give away' markers, it takes what it needs and
leaves the rest as available? Then the containers wouldn't need to
change unless they are using the default marker.

almostautomated

[Neil Hodgson]

almostautomated:

> Could the defualt marker type be SC_MARK_AVAILABLE so instead of a
> container needing to 'give away' markers, it takes what it needs and
> leaves the rest as available?  Then the containers wouldn't need to
> change unless they are using the default marker.

Its safer for the default to be not available. Existing containers
are written assuming they are the only thing allocating markers. Some
of them will leave the symbol as SC_MARK_CIRCLE and not bother setting
it. If a container wants to support marker availability then it can
choose to change them to available.

Neil

[almostautomated]

>    Its safer for the default to be not available. Existing containers
> are written assuming they are the only thing allocating markers. Some
> of them will leave the symbol as SC_MARK_CIRCLE and not bother setting
> it. If a container wants to support marker availability then it can
> choose to change them to available.
>
>    Neil

Understood, and thanks gain for this addition to Scintilla.