In case you are not familiar with what a drop target is.  It can be a box or window open by a program to accept a list of files.  To be dropped into the drop target box.   The drop location could also be a location inside a program that will process a list of files dropped there.

Using shell and dir to capture a list of files is too much sledgehammer approach to a pin prick need.  This will most certainly require a DLL call.  And I am clueless to know how.  This could be a good routine inclusion, would become a nice touch for QB64 tools.  Stuffing the clipboard would be likely the best way to get them in.

Thanks

So how do we get 150,000 new QB64 users.  With sales of 30 Million unit's in 2019, who knows where that number is today with covid locking people at home.  And any available unit being scalped at ridiculous prices.  Or any online listing announcing stock all gone within 15 minutes.  The little sought after PC is the Raspberry PI.  If we can get 0.5% of the user base to install it's 150K new users.

So what will it take to get QB64 listed in the Raspberry Debian Repository ?  There are many locations the where repositories are holding code.  I could be wrong but all we need is one developer to compile and post a image of QB64 and support files.  I now the install script exists to compile QB64 but it's not "ALL" new user friendly.  I think we need to "APP" QB64 into a repository package.

So can we make this happen ?  I would love to help but I am too newbie even after a couple of years using Linux to know how to do this.

Thanks
BTW, With all the competition QB64 has under windows.  Nobody has listed there basic in the repository.  We could be a first.
 

Why would I even discuss the matter if it was that simple.  Both IDE's in my opinion should have puked for syntax not compile and run.  The results were the same for both.  I was going to create a temporary value f$.  Realized I wasn't going to do anything more with f$.  Decided to output the f$ directly to file. I did this: (the wrong way)

Do Until EOF(1)
    Line Input #1, f$
    p = InStr(17, f$, "\")
    Print #2, f$ = Right$(f$, Len(f$) - p)
Loop
System

Forgot to remove the "f$ = ".  My brain was on autopilot and fingers were just doing there thing.  IMHO, the IDE's should have puked.
I made a Blonder not blunder, see a previous post thread.

Now, somebody is going to say the precompiler could not possibly find all faults. (Granted!), But we have taken so much to being true to QB45, Even errors are the same.

OK, let the bashing commence.

Before the next release of QB64 it would be nice to fix problems with differences.  Mainly there are some things that will not work and cause problems or just work strangely.  The only one I know right off the bat is READ/DATA statements in the language.  Does not work.

Way back when the QB64 got a 64 bit release there were a number of issues.  (more than just 1).  Is it possible to fix as many of the problems before the next release ?  I really want to go all 64 bit.  Can't since a couple of my programs won't work 64!

Since someone, mentioned "lint" for QB64.  Got me to thinking about "Crossref" lists.  Back when I played with assembler.  It was possible to specify Crossref list generation at the end of the listing.  The crossref would list all variables used and what line numbers contained them.  As well as all labels and locations.  It was convenient to find all references and impacts to code.  Things like changing byte to word, became a snap.  You could look at all the cross refs, and figure out things.

Anyway to get this from listing/compiles ?
Or am I barking up an old dead tree ?

What I am about to say, is normal in QB45.  <------
In a=VAL(A$) example.  The variable 'a' becomes the numerical representation of A$.  Conversion using VAL converts until a non-numeric value is encountered.  This is unless prefixed by &x.  X being some base like hex (&H).  My high school days I was taught 0-9 are numerical.  A-F are accepted for hex.  Keeping that in mind, what do the following conversions output ?

5555
5 5 5 5
5555G4444
5 5 5 5 G 4 4 4 4
&H15B3

If you say 5555 you are right!!  Now the gotcha.  Why is space considered a numeric ?  A leading space yes, to determine negative or positive numbers.  But space in between all numbers.  Give me a break.  Even Wikipedia gave a non-answer answer (best I could find).

I said I was going to try speeding up my little txt searching program.  Well I got some nasty results.
I am substituting pipe.h command with my shell usage.

#1 the end of line delimiter became chr$(10) from chr$(10)+chr$(13) <-- nothing nasty here.
#2 not using the clipboard to pass data back  <-- nothing nasty here.
#3 does not require "cmd /c " to make use of "findstr" windows search program.  I can just use it.  <-- nothing nasty here.

Clean up the program a little, save it and compile.  Then the nasty part begins.

I  R U N  I T !!  Fortunately for me a used a small test list.  "Very fortunately".

When you use the pipe cmd dozens of times on name variations it will call pipe cmd 1000's of times.  In my test list.  What could be so nasty about that??  Well every time the pipe is called a new terminal window opens and gains focus then closes.  It's really nasty when focus changes so fast you can't do a damn thing to: stop, terminate it, close it or any other it within windows.  You just have to let "IT" finish.  When you can get control back.  (hard or soft) Shutdown and reboot was not a option in my case.  Loss of so much else would happen.

Unintended consequences. BUG.  Bet you didn't see this one coming.
Edit not a bug but intended.

after much looking over things.  I would like to pull back this post.

edit: What brought this up.

The shell function does not just bring up another command.com instance.  I was trying to use the "findstr" program within a shell.  Nothing happened.  I thought maybe the path was not pointing right.  I used explicit path to "findstr" in syswow64.  Still nothing.  I directed my shell passing stuff into a .cmd file.  Executed it  from a plain dos prompt.  Worked.  I executed my created .cmd from a shell.  Worked.  The help content on shell function mentions using "cmd /c" because somethings don't work right with just shelling.  Did that and it worked.

The nasty part about this the shell should work without invoking another command.com from my shell out.  Beware shell is NOT A EXECUTION OF COMMAND.COM with parameters.  There are strange limits.

I still wish for a un-post button for a post by the "poster".
edit: Title change a bit for a warning about shell.