Fields and lines...[Solved]

[bogs]

I hope someone can set me straight on this behavior, as I am unable to figure out why it is happening.

I have a simple stack, with a field on it.
.. in the field are a number of lines.
.. I am trying to replace 2 of the lines without changing the placement of the rest of the lines.
Here are the lines I am working with -

Code: Select all

[Desktop Entry]
Version=1.0
Type=Application
Name=BubbleTimer
Comment=Simple time length recording timer.
Icon=/home/bogs/Lc_Projects/Lc6_5-6_7/bubbleTimer/bubbleIcon2.svg
Exec=/home/bogs/Lc_Projects/Lc6_5-6_7/bubbleTimer/BubbleTimer
StartupWMClass=BubbleTimer
Terminal=false

I want to replace lines 6 & 7 with strings in variables, so my thinking originally ran to the simplest commands I could come up with,

Code: Select all

 put "icon=" & tmpPath & tmpFiles into line 6 of field 1
 put "Exec=" & tmpPath & tmpName into line 7 of field 1

In this case, tmpPath and tmpFiles hold the location of a picture and the path to an exectuable, tmpName holds the exectuables name.

However, when running the code, the field goes from this -

Original...

To this -

Wth ?

Which looks like at least one line not worked with got blipped out (Comment=), and empty lines added.

I've tried instead using replace, replaceText, deleting the line then putting it into the line, inserting before or after the line then deleting the next line (which kind of works), but I am stumped as to why it can't just be put into the original line without moving or removing other lines

Thank you in advance for any information provided

[[-hh]]

You could check the line endings of your field before replacing.
Probably this is copied from a file that has "mixed" line endings.

[bogs]

Hm. That certainly is a thought that never occurred to me, the text was created in a basic text editor (Leafpad) on a linux system (antiX) and then copied/pasted into the field. It would be wierd if the line endings were mixed in type, but not impossible. I'll check that and then come back with the results.

Edit - the results ~
Far as I can tell, the file doesn't contain mixed endings. I ran a number of check commands.

Checking CRLF status...

All came back clean.

Edit 2 -
Just to make sure I hadn't made a mistake from the command line, I opened the file in Geany.

Geany, show me the line endings!

[[-hh]]

If you do such inserting by script(put url(...)) then you should also make sure that the file is UTF-8 (for LC 8/9).
Also I saw that you use versions < 8 with this project. If you switch between LC 6 and LC 8/9, then line ending problems may also occur.

[bogs]

If you do such inserting by script...

In this case, the text is simply copied from Leafpad to the field. Only which lines need to be changed are scripted. Good thought though!

The versions of the IDE I use are Mc, and Lc 6.5.2 primarily. I don't use versions higher than that unless I am trying to answer someone elses question, so no worry on bringing it up to 8

In this case, it is straight Lc 6.5.2.

From your answers, am I right in assuming that putting the text directly into line x of field x *should* work the way I am thinking?

[[-hh]]

It should work if your insertions are one line (don't contain return), else you should replace first line 7, then line 6.

Of course LC converts text from clipboards when pasting.
Better try to get the file via
• url("file:"&....) -- converts line endings
• url("binfile:"&...) -- doesn't convert line endings

and see if there is a difference.

[bogs]

Hmm, I wasn't planning on including the text file in use, the field is where the original would be kept, but just to make sure, I tested your suggestion.

The code to load the file -

Code: Select all

  put  url("file:" & tmpPath & "/lines.text") into field 1

which appears correct -

Loaded text...

but I still get the goofy result when changing the 2 lines I need changed -

Hmmm....

Just to make sure I wasn't outputting some goofy mixed format, I checked the file being written as well -

LF all the way, yaaayyy!

[richmond62]

Try making sure your field is a scrolling list field:
-

brains.png (12.31 KiB) Viewed 5367 times

-

Code: Select all

on mouseUp
   put "monkey's brains" into line 1 of fld "f1"
   put "cauliflowers" into line 3 of fld "f1"
   put "risorgimento" into line 7 of fld "f1"
end mouseUp

[bogs]

After reviewing Hermann's input again, I manually typed the entries into a separate field, then put that fields contents into the field that will be edited just to make sure Lc was playing with all the same marbles as it were, but still no joy

Top field manually typed in, copied to lower field, then lower field edited by script...

Before the lines are inserted through script, the bottom and top field are identical.

Try making sure your field is a scrolling list field:

The fields I am using are just base fields (with scrollbars checked), but shouldn't putting the line into the field work without creating this kind of havoc regardless?

The code that is causing this is just

Code: Select all

put "icon=" & tmpPath & tmpFiles into line 6 of field 1

No cr, no return, no LF, just trying to replace one line with the new line.

[richmond62]

but shouldn't putting the line into the field work without creating this kind of havoc regardless?

I have a funny feeling line numbers don't behave themselves in "plain, vanilla" text fields.

[bogs]

Hmmmm....

Edit - Following Richmond's suggestion, I substituted a scrolling list field for the base field and fed in the same code, and got the same result.

Hmmmm....

Me thinks I is beginning to smell a bug

Edit 2 - I see the same result on Win7 in 9.0.1, so I'll go check the bug reports now.

Win7 Lc 9.0.1...

[bogs]

Well, I finally did figure out what (or I should say, *where*) was going wrong in the code for me, it isn't a bug though

Here is the code that starts the issue -

Code: Select all

 put "" into tmpFiles // clear tmpFiles...
   repeat for each line x in the files
 // this puts an extra empty line at the end of the list I didn't take into account ...
      put x & cr after tmpFiles
   end repeat
   filter tmpFiles without "*.*"
   // put the name into the correct location in the field...
   put tmpFiles into tmpName
    put "Name=" & tmpName into line 4 of tmpFieldContents

Of course, that unaccounted for (by me) empty line caused the whole problem, by shifting the number of lines in the field, which I corrected with this change

Code: Select all

// put the name into the correct location in the field...
   put line 1 of tmpFiles into tmpName

Here is the picture proof of my own idiocy

What a dingbat!

I certainly want to thank Hermann and Richmond for the suggestions, sorry for the false alarm

[jacque]

There is a religious war about whether line (and other) ending characters should be delimiters or simply markers that are part of the text chunk. The current behavior is to consider them as part of the chunk, and that works well in more situations than delimiters would. LC strips off the marker when you ask for the contents of the chunk, otherwise it remains.

If that's a problem, the usual fix is to remove the last marker (CR in this case) before manipulating the field. Or just filter the resulting field "without empty" after an operation that affects the results.

Mark Waddingham provided a good explanation for why these markers could not be used as delimiters but I can't remember where it is.

[bogs]

There is a religious war about whether line (and other) ending characters should be delimiters or simply markers that are part of the text chunk.

You know, I'll believe whatever you tell me too, 'o mighty 'o powerful omnipotent shtomper!

the usual fix is to remove the last marker (CR in this case)

Yah, if I had known there was an empty line below the one I had needed after filtering tmpFiles, I would have saved myself a lot of frustration

Somehow, though, it never occurred to me there was an empty line to deal with until I stepped through it, and even then I stared at that variable for hours. If I had just stuck a cursor in there at *any* point, or counted the lines of it, or any number of other things that would have equaled more than '1', the agony would have been far less

I swear my brains go out on random walks of their own when I'm not looking but hopefully this page will save some other poor soul some headscratching

[richmond62]

There is only one thing that has to be considered, decided on,
and THEN made explicit in the documentation.

And that is whether a "bog normal" textField has line number that can be addresst
in the same way as lines in a scrolling list field can be addresst or not,
and if they can't it micht be time to introduce a text field that is NOT scrolling but is STILL a list field and
plonk an icon for that on the toolbar.rev palette.