PureBasic Forum

when you click on a member of the panel procedure to the right of the editor.
how do you do with scintilla to jump on the right line of code?
whatever the size of the code, it seems instantaneous !!

do you use a particular trick?
how do you do that?
I mean the link that links the line of code whatever its position, and the word in the "procedure" panel
there is a "tag" on the line of code that allows you to jump on it?
I went through all the scintilla doc without seeing how to do that

***********************************************************************
***********************************************************************


in French:
lorsqu'on clique sur un membre du panel procedure situé a droite de l'editeur .
comment faites vous avec scintilla pour sauter sur la bonne ligne de code ?
quelque soit la taille du code , cela semble instantané !!

utilisez vous une astuce particuliere ?
comment faites vous ça ?
je veux parler du lien qui relie la ligne de code quelque soit sa position , et le mot dans le panel "procedure"
il y a un "tag" sur la ligne de code qui permet de sauter dessus ?

j'ai parcouru toute la doc de scintilla sans voir comment faire ça

Either an internal function of Scintilla

Either a map :


Have to be prepared during the loading and updated every time a line is added or removed.

You could make a change list (adding/removing) to set the updates in the right time. What it could prevent from lag during many successive carriage returns inserting i.e. .


(french)
Soit une fonction interne de Scintilla

Soit une map : code du dessus.
Ça a à être préparé durant le chargement et la mise à jour chaque fois qu'une ligne est ajoutée ou supprimée.

Tu pourras faire un journal d'ajouts et de suppressions pour faire les mises à jour au bon moment. Ce qui empêchera les lags pendant l'insertion de beaucoup de retour chariot successifs, par exemple.

Maybe something like this?!

I don't know how it is implemented in PB ?
I think you need to keep it as simple as possible. Considering that the editor's content is in memory, then a simple text search is sufficient. Thus, there is no need to recalculate the position each time a line is added or deleted.

I tested: in PB (FindString), the search for a string (last line) on a text of 390,000 lines (23 MB) took 38 milliseconds (debug off) on my small Intel i3

Now see what it looks like with the Scintilla function ?

https://www.scintilla.org/ScintillaDoc.html#Searching
SCI_SEARCHINTARGET

@chi

Good. However, normally native map could insure better than CRC32 : I think you have some details to see this here i.e. .

But if you want grow your algo op in your code, we could see it is easy to do. Good example your code.

@chi : Thanks , I will go see



I tried to remember the number of the line
(loading, or even changing the code)
it works unless we add (or remove) lines

the problem is that the content of this line may change
line 30 = debug "procedure foo ()"
if I retain the line number, and add a new line
"procedure foo ()" is found on line 31 ... (see more)

my line number 30, no longer serves me to jump in the code where is "procedure toto () ....
maps or lists () in this case, do not serve me anymore ....
............................................
until now, I'm rebuilding my list which contains the name "procedure foo (), and its line number
every time you edit the text ...

it works but:
but on a list of 9000 lines, the list path takes several seconds .. (so at each press on a key of the keyboard)

@ Marc56us

searching using findstring () is not reasonable ...
it does not return the number of the line where the term is found .... it only sends me its position in characters ...

if I look for findstring ("procedure foo ()"), I will not know which line is "procedure foo ()" ....

the goal is to be able to jump on this line number ...

but, you're probably right .. I have to find the line number AND position in character in the listing .... humm .. not simple


I thought perhaps, to have passed by a subtlety of Scintilla on this subject, a form of Tag, which will keep the number of the line according to its content ...



in French :

j'ai experimenter de retenir le numero de la ligne
(au chargement , ou meme a la modification du code)
cela marche ,sauf si, on n'ajoute (ou retire) des lignes

le probleme c'est que le contenu de cette ligne peut changer
la ligne 30= debug "procedure toto()"
si je retient le numero de ligne , et qu'on ajoute une nouvelle ligne
"procedure toto()" se retrouve ligne 31... (voir plus)

mon numero de ligne 30, ne me sert plus pour sauter dans le code ou se trouve "procedure toto() ....
les maps ou les lists() dans ce cas , ne me servent plus ....
............................................
jusqu'a maintenant , je refabrique mes list qui contiennent le nom "procedure toto() , et son numero de ligne
a chaque modification du text ...

cela fonctionne mais :
mais sur un listing de 9000 lignes , le parcours des listes prends plusieurs secondes .. (donc a chaque appuis sur une touche du clavier)

@Marc56us

la recherche en utilisant findstring() n'est pas raisonable ...
elle ne renvoie pas le numero de la ligne ou se trouve le terme recherché ....elle me renvoi seulement sa position en caracteres...

si je cherche findstring("procedure toto()") , je ne saurai pas sur quelle ligne se trouve "procedure toto()" ....

le but c'est de pouvoir ensuite sauter sur ce numero de ligne...

mais , tu as probablement raison .. il faut que je trouve la correspondance numero de ligne ET position en caractere dans le listing .... humm.. pas simple


je pensais peut etre , etre passé a coté d'une subtilité de Scintilla a ce sujet , une forme de Tag , qui garderai le numero de la ligne en fonction de son contenu ...

Yes, but with PeekS we define the memory area up to the point found by FindString or SCI_SEARCHINTARGET and then with CountString, we count the number of #CRLF to get the line number

-- Fr
Oui, mais avec PeekS on défini la zone mémoire jusqu'au point trouvé par FindString ou SCI_SEARCHINTARGET et ensuite avec CountString, on compte le nombre de #CRLF pour avoir le numéro de ligne. Ça peut paraître du bricolage, mais 9000 lignes, c'est rien pour ces fonctions
De plus, on ne lance la fonction que lorsque l'utilisateur clique sur un bookmark et non pas à chaque ajout / suppression de ligne.

[Edit]
Et même sans PeekS (par simple copie de la partie gauche de la chaine): 7 ms! sur mon petit Intel i3 pour trouver le numéro de ligne sur un fichier de 39.156 lignes
"Think simple"

Autre test: Fichier de 23 Mo, 390.000 lignes = 137 ms !

Autre méthode: On trouve parfois de la doc en cherchant 'named bookmark'

@Marc56us

Wait a little bit : dobro wants his software to find valid procedure name.

We must consider :

- macros
- compiler options
- modules
- single quote
- double quote
- comments
- case non-sensitivity




(french)

Attends un peu Marc56us : Dobro veut que son soft trouve les noms de procedures valides.

On doit considérer : la liste ci-dessus.

No, Read it again carefully he just want the line number that match the selected item in his procedure list in his EPB IDE (like PB do in his IDE)
The automatic feeding of the list is something else and it's even easy to do (with RegEx)

For the moment he has not specified if he wants to search in the modules, includes, comments etc.
It's just marked text, not necessarily valid procedures.


-- Fr

Non, relis bien il veut juste récupérer le numéro de la ligne dans l'éditeur pour ensuite positionner le curseur sur la ligne (dans son EPB)
Et c'est ce que fait mon bout de code pure PB.
Il suffit de chercher le texte, puis de compter le nombre de saut de lignes avant la chaîne trouvée.

Pour l'instant il n'a pas précisé s'il veut aller chercher dans les modules, includes, commentaires etc. C'est juste du texte marqué, pas nécessairement des procédures valides.
L'alimentation automatique de la liste c'est autre-chose et c'est même facile à faire (avec les RegEx)

@Dobro: J'arrête là mes traductions, c'est long à faire. Si tu veux en discuter plus, viens sur le forum Fr.

Oh... Well I will sleep...


(french)

Ah... bon ben je vais pioncer...

@Marc56us Thanks, good idea

Thank you and good idea your thing to count the end of lines ..
I'm going to look at your example, thanks again