Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mac _CLIPBOARD$ Bug??
#1
Pardon the ignorance of a newbie. I've been using QB64 off and on for years, I'm not really sure of it's relationship with QB64PE. I'm using what I think is the latest QB64 version 2.1, but I see the PE version is at 3.5.0?

Anyway, here is my issue:
Dragging and dropping into a BASIC program doesn't work on a Mac. So I have found it very useful to use the clipboard commands. I can easily find a file using Finder (the Mac equivalent of File Explorer) and copy it to the clipboard for my BASIC program to use. The problem I have is trying to extract the PATH information for the filename on the clipboard.

In Finder if you select files/folders, then right-click on them, you can copy them to the clipboard. But it doesn't copy the PATH information. But there is a way. Right-click on the files/folders. Instead of clicking on the "Copy" entry, hold down the [Option] key. "Copy" becomes "Copy as Pathnames". It copies the entire PATH and filename to the clipboard. If you are keyboard centric, use [Command]+[Option]+[C]. But there is a snag (bug?) with _CLIPBOARD$. It doesn't return all the data from the clipboard properly when there are file PATHs involved. Here is a simple program:

_CLIPBOARD$ = ""
PRINT "Copy the files to the clipboard."
DO UNTIL _CLIPBOARD$ <> ""
LOOP
CLS
PRINT _CLIPBOARD$
SLEEP
SYSTEM

If I select multiple files/folders in Finder, _CLIPBOARD$ returns all the titles (without the PATHs).
If I select multiple files/folders with their PATHs as described above, _CLIPBOARD$ only returns the first title. I know it contains all of them because I can paste to a blank document and they are all there with their PATHs.

For example, if I select the following files using “Copy Items”:

/Applications/QB64/Programs/File1.rtf
/Applications/QB64/Programs/File2.txt
/Applications/QB64/Programs/File3.pdf

_CLIPBOARD$ returns:
File1.rtf
File2.txt
File3.pdf

If I select them using “Copy Items As Pathnames”, _CLIPBOARD$ returns:
/Applications/QB64/Programs/File1.rtf

But if I paste the clipboard into a blank document I get:
/Applications/QB64/Programs/File1.rtf
/Applications/QB64/Programs/File2.txt
/Applications/QB64/Programs/File3.pdf

So I know the information is there, I just can't get to it. On a Mac the clipboard is loaded by either "Copy to clipboard" or "Copy path to clipboard", in either case QB64 should be able to read the contents of the clipboard.

Any help with this would be greatly appreciated...
Reply
#2
I would be interested to know if the Open File Dialog works in Mac. For this you need a recent version of QB64pe
https://github.com/QB64-Phoenix-Edition/...tag/v3.5.0

Check out the wiki: https://qb64phoenix.com/qb64wiki/index.php/Main_Page
Look up _OPENFILEDIALOG$
Basically retrieves file name(s)
b = b + ...
Reply
#3
Here's how it works for Windows, I don't have Mac to test it on but you aren't depending on Mac's Clipboard.
Code: (Select All)
f$ = _OpenFileDialog$("Get File to process", _CWD$, "*.bas", "any bas file", -1)
ReDim fArr$(1 To 1)
Split f$, "|", fArr$()
For i = LBound(fArr$) To UBound(fArr$)
    Print fArr$(i)
Next

' note: I buggered this twice now, FOR base 1 array REDIM MyArray (1 to 1) AS ... the (1 to 1) is not same as (1) which was the Blunder!!!
'notes: REDIM the array(0) to be loaded before calling Split '<<<< IMPORTANT dynamic array and empty, can use any lbound though
'This SUB will take a given N delimited string, and delimiter$ and create an array of N+1 strings using the LBOUND of the given dynamic array to load.
'notes: the loadMeArray() needs to be dynamic string array and will not change the LBOUND of the array it is given.  rev 2019-08-27
Sub Split (SplitMeString As String, delim As String, loadMeArray() As String)
    Dim curpos As Long, arrpos As Long, LD As Long, dpos As Long 'fix use the Lbound the array already has
    curpos = 1: arrpos = LBound(loadMeArray): LD = Len(delim)
    dpos = InStr(curpos, SplitMeString, delim)
    Do Until dpos = 0
        loadMeArray(arrpos) = Mid$(SplitMeString, curpos, dpos - curpos)
        arrpos = arrpos + 1
        If arrpos > UBound(loadMeArray) Then ReDim _Preserve loadMeArray(LBound(loadMeArray) To UBound(loadMeArray) + 1000) As String
        curpos = dpos + LD
        dpos = InStr(curpos, SplitMeString, delim)
    Loop
    loadMeArray(arrpos) = Mid$(SplitMeString, curpos)
    ReDim _Preserve loadMeArray(LBound(loadMeArray) To arrpos) As String 'get the ubound correct
End Sub

   
As you can see multiple Pathed Filenames.
b = b + ...
Reply
#4
(01-23-2023, 09:57 PM)tothebin Wrote: Pardon the ignorance of a newbie. I've been using QB64 off and on for years, I'm not really sure of it's relationship with QB64PE. I'm using what I think is the latest QB64 version 2.1, but I see the PE version is at 3.5.0?

Welcome to the forums.

QB64 v2.1 is from the "official" version which could be had from:

https://qb64.com/

QB64PE v3.5.0 is Phoenix Edition, which is a distinct branch of QB64. This forum is chiefly about Phoenix Edition but things could be discussed about QB64 since it was started by Galleon. Specifically there is a forum to talk about other BASIC dialects, and there is another forum for off-topic from QB64(PE).

Quote:If I select them using “Copy Items As Pathnames”, _CLIPBOARD$ returns:
/Applications/QB64/Programs/File1.rtf

But if I paste the clipboard into a blank document I get:
/Applications/QB64/Programs/File1.rtf
/Applications/QB64/Programs/File2.txt
/Applications/QB64/Programs/File3.pdf

So I know the information is there, I just can't get to it.

This might be an CHR$(0) around somewhere, or MacOS processing ends at newline which is just CHR$(13). (shrugs)

Quote:If I select multiple files/folders in Finder, _CLIPBOARD$ returns all the titles (without the PATHs).

This might be because the programming system has no way of knowing which is the "current" directory, and Finder might not be helpful about it. This is just a wild guess, since I don't have a Macintosh. :/
Reply
#5
Setting up QB64pe under Mac might be huge ordeal but the Development team would likely be very interested in your experiences and eager to help you get set up.

Plus the Basic community would benefit from that OS perspective.

So @tothebin I know it seems easier to do things with Clipboard and the QB64 you have in short term but in the bigger picture? ...Needs a bigger man ;-))

OTOH maybe _Clipboard has a bug in QB64 or Mac, if we could compare results with OpenFileDialog it might give us more info.
b = b + ...
Reply
#6
I appreciate all the feedback. My time is a little limited right now, but I do plan on installing PE and I'll let you know what happens. I don't mind testing Mac related stuff if someone has a need. I should have something in a day or two.
Reply
#7
I would just lie a moment to say "Thank you" to everyone who replied. I got QB64pe working and it made a huge difference. Pardon my mansplaining while I do a little happy-dance around what has happened. A lot of people seem to be using QB64 to run old game programs. I wanted to use it to write some utilities to make batch file processing easier. 

Most recently I am doing the following to process movie files:
Take folders full of MP4 video files and batch rename them with episode numbers and titles in the filenames.
Feed them into an app to compress/convert them to MKV, which also converts the MP4’s built-in TXG3 subtitles to SSA.
Feed the output to another app to extract the SSA subtitles.
Use BASIC to convert/clean the SSA files into SRT files, while stripping away closed captions.
Feed the compressed MKVs into another app along with the SRT subtitles and additional JPG cover art while stripping/changing/creating file data to produce a finished and properly formatted MKV, without extraneous tags/attachments.
Change the icon and creation/modification dates for the files.
Clean up the files/folders used in the process and pack away a log file of everything that was done.

Yes, that's all really time consuming manually, but has the potential to be really easy using a BASIC program. I had hoped to use file dragging and dropping so I wouldn't have to write an entire system of dialog boxes. But QB64 doesn't support file dragging and dropping on a Mac. So I tried using the clipboard to mass select files/folders, and that ran me into the problems listed previously with extracting Path information. Then some wonderful people pointed me towards QB64pe, and the _OPENFILEDIALOG$ and related commands. Wow what a difference! All the code I was going to have to write for dialog boxes and file selection was already written in a few simple commands! And I don't need to use the clipboard to get there! 

I still had QB64 installed on my computer (macOS High Sierra). I installed the Xcode software anyway, and tried to install QB64pe, which failed. I was pointed to another build (qb64pe_osx-3.5.0-18-6b9274e64). That build installed properly but with a warning
.txt   Install warning.txt (Size: 11.19 KB / Downloads: 53) . I ran both versions at the same time and noticed a peculiarity with the clipboard, not the commands but the Mac clipboard itself. When I tried to copy something from the QB64pe IDE to the clipboard and paste it into a TXT file (using [CTRL]+c for the IDE and [CMD]+v for the Mac), it wouldn't work. Instead of pasting what I had just copied to the clipboard it pasted something I had copied earlier. But if I copied from a TXT file and pasted to the IDE, that did work. It also worked copying and pasting between IDEs. But if I then tried to past back to the TXT file the old info pasted again. It was as though there were 2 clipboards being used. The same thing happened when I tried it in the QB64 version. In the end, when I rebooted and tried again everything had fixed itself. The clipboard acts normally now. But the file path problems I had with the clipboard haven't changed.

Fortunately the new commands available in QB64pe make the clipboard stuff irrelevant at the moment. I can use the pe commands for my interface and don't need to resort to using the clipboard. So far everything I've tried in QB64pe has worked as designed, with only one small glitch. When I go to options>display and change the default window width, it sometimes takes a couple of tries before it accepts the change. Not a big deal.

Thanks to QB64pe and the people in this forum I am now on my way towards a better and simpler version of my program, and really looking forward to coding again!

By the way, I was asked if the dialog box commands worked well on the Mac. So far they work beautifully, with one tiny annoyance. _OPENFILEDIALOG$ creates a dialog box in the middle of the screen. I am not aware of a method for determining where it opens. I can click on it and move it, but the next time it opens it goes back to the middle of the screen instead of where it was the last time I closed it. This is so trivial I almost didn't mention it. But since development is ongoing I supposed I should say something.
Reply
#8
I am glad things are working better for you!
b = b + ...
Reply
#9
Thank you again for everything. I'll try to post some useful code when I get through this.
Reply
#10
If the number of files to convert is really large like a thousand or more, it might be better to create a text file which each line is the full path to one subject file. I know on Linux "find" terminal command could be used for this purpose, but I don't know what is it for MacOS...

The "open file dialog" way is good if the files are in a single directory. But if you have many directories to process as well, then it could be more time-consuming and trying, especially if the conversion process for each file takes a long time.

It's possible to fabricate a batch file to do the repetitive processes to convert, to rename and stuff like that but it takes practice and patience, and only try it on a few files during debug mode, not like me, at least one time, who had to use it on hundreds of files and waited for all output to finish. Rolleyes
Reply




Users browsing this thread: 3 Guest(s)