corneliusdavid

You're on the right screen: it's Code parameters. The Delay affects how quickly the tooltip will appear (or at least that's the idea--it doesn't display at all for me automatically if the delay is anything but "None").

You can always manually activate it by hitting Ctrl+Shift+Space.

Yes, IB uses "simple" case.  Try this:

SELECT O.DELVTYPE, SUM(OD.REMAINQTY) QTY,
       (Case O.DELVTYPE 
          When 'Sea' then O.DELVDATE + 45 
          else O.DELVDATE + 15 
        end) as DELVDATE
FROM ORDETAIL OD
JOIN ORDERS O ON O.RNO=OD.RNO
WHERE OD.ITEMNO = 'ABX22'
GROUP BY O.DELVTYPE, O.DELVDATE  
HAVING SUM(OD.REMAINQTY) > 0

Re-reading the StackOverflow question and looking more closely at my HTML, I realized I was missing the name attribute in the input element. Now my Files property is being filled and I can save the uploaded file. 🙂

<form action="UploadFile" method="post" enctype="multipart/form-data">
  <label for="MyFile">Select file to upload:</label><br />
  <input type="file" id="MyFile" name="MyFile">
  <button type="submit">Upload</button>
</form>

I've got a small WebBroker application that requests the user to choose a file which is then posted to another page of the WebBroker application. The web form's HTML is like this:

 <form action="UploadFile" method="post" enctype="multipart/form-data">
  <label for="MyFile">Select file to upload:</label><br />
  <input type="file" id="MyFile">
  <button type="submit">Upload</button>
</form>

The TWebApplicationItem that handles the "/UploadFile" path is trying to get the file to upload so it can save it on the server but I can't find documentation or an example of how to do this.

I've tried looking at both TRequest.ContentFields and TRequest.Files properties but they're always empty. I found an old StackOverflow question relating to this that mentioned including the ReqMulti unit so that it parses the multi-part form but that didn't fill the Files property for me. Finally, I called Request.ExtractContentFields but it just gave me the same raw string, ('------WebKitFormBoundaryBRM3RcInbYBqzsVj--') that I saw in the TRequest.Content property. From what I've been reading, I should be able to create a TFileStream and somehow use the Content property to read the file from the headers but I'm not sure how to get the file information.

Can someone point me in the right direction?

Wow--OK.  This is more confusing than I first thought--I have more study to do on this!  Thanks for pointing that out.

@Dave Nottage, thanks for that explanation. To further clarify my situation and after looking at my project again, my target SDK is only at 25.2.25 so while that works on my Android 11, it doesn't support all the newest features of Android API 30.

5 hours ago, MikeMon said:

Is it safe to follow @vfbb 's post above?

All I know is that it is working very well for me. I've got a Delphi app on my Android 11 phone that I actively use and it works well.

58 minutes ago, Randall Carpenter said:

We have apparently registered one of the Serial numbers too many times.  If I load the IDE, the message appears that I have too many copies running. 

Registering a serial number too many times is one problem--and easily solved by requesting a registration number bump. However, your second sentence indicates a different problem: You have too many copies of Delphi running with the same serial number.  I believe the max is 2.

I run into this once in a while if I leave Delphi up in a virtual machine and switch to a different VM to check a different project. If I forget to close one of them down and then leave the office with my laptop and try to use Delphi on that, I get the warning and have to remote into one of the VMs and close one down.

So, using your second serial number to register a second copy of Delphi should solve your problem.  And to answer your question, no, registering Delphi does not affect third party packages.

Sometimes this happens to me as well but then I realize I had a file open from a different project or the line of code was excluded because of conditional compilation of some sort. Other times, the background compiler that does syntax checking just hasn't realized the line of code is able to be debugged; in that case, I just do a project Build All and it often solves the problem.

I presume you've tried going into Project > Options > Application > Icons and setting all listed resolution image filenames under the Launcher, Notification, and Splash Images tabs?

It's in my copy of Delphi 10.4 where I would expect:

• \source\fmx\FMX.Graphics.pas
• $(BDSLIB)\$(Platform)\release

Yes, DosCommand has both Delphi and C++ Builder packages to do exactly what you need.

There are several different licenses for different installation types of InterBase, but I'm assuming you're not using the Developer, Desktop, ToGo, or IBLite licenses.

I'm pretty sure that it is not tied to a specific CPU or computer however, if one instance of a licensed InterBase is running and a second instance with the same license starts up, I think you'll get a license error. Whether or not Embarcadero tracks where the license is coming from, I'm not sure.

Excellent!  You're welcome.

procedure TForm1.MenuItem1Click(Sender: TObject);
var
  I: integer;
  list: TStringList;
  AItem1: TListViewItem;
begin
  list := TStringList.Create;
  for I := 0 to ListView1.Items.Count - 1 do
  begin
     AItem1 := ListView1.Items[I];
     name := AItem1.Data['Text1'].AsString;
     phone := AItem1.Data['Text2'].AsString;
     index := AItem1.Data['Text3'].AsString;
     list.Add(name + sLineBreak + phone + sLineBreak + index + sLineBreak);
  end;
  list.SaveToFile('C:\Users\Gt\Desktop\TestContactBack.vcf');
  list.Free;
end;

You don't need ListView1ItemClick at all for this.

Don't assign the Selected property at all--that's not going to help you. Replace that line with the name, phone, index assignments from ListView1ItemClick.

Setting .Selected isn't changing what AItem is pointing to, so AItem never changes. Instead, you would want to assign AItem:

AItem1 := ListView1.Items[I];

Then you could access the item's data.

The WebBroker project is a cross-platform project, compiling to Windows or Linux depending on the platform selected.  Therefore, all the code, data modules, settings, etc. are exactly the same between the two. This all runs on my Windows 10 machine where I have 1) IIS, 2) Apache for Windows, 3) Apache for Linux in a Linux subsystem, all running simultaneously but listening on different ports. The database is an InterBase database on a different machine. All data from all apps on all platforms are pulling from the same table from the same database.

Yes, I'm sure there's data--I can see it by simply switching the port on the browser's address line to access a different web server to test it out. And, like I mentioned previously, a different web action item in the same WebBroker project that queries for a specific record (without using the DataSetTableProducer) works just fine on all platforms, even Apache for Linux. This alone verifies the Apache for Linux version of the project is connecting successfully to the database and can return data--and that there is actually data.

For an example of what this looks like, you can visit MyParks.net which is running a separate copy of this project I built for IIS before doing the Apache version.  All the code and data modules are the same (except for some minor differences in setting up logging) and it points to the same database from which I'm testing the Apache versions.

The code I showed above is pretty minimal. The logging is from LoggerPro and simply writes a line to a file. The dmParksDB.OpenParks simply opened the FireDAC query, which as I looked at the source for the DataSetTableProducer, realized is completely unnecessary. So basically, the code above could be reduced to:

try
  Result := dstpMyParks.Content;
except
  on e:Exception do
    Log.Error(e.Message, LOG_TAG);
end;

which does not call any of my library routines until logging the error message in the exception handler, and there are no errors in the log (but plenty of log messages before and after this).

And for the record, I modified my code to look like the above with no change.

I should also note I have been using a regular PageProducer to show nice headers and footers with an HTMLTag in the PageProducer's HTML that gets replaced in OnHTMLTag with the DataSetTableProducer.Content in the code above. I replaced that PageProducer and hooked it up directly to the DataSetTableProducer which still works for Apache for Windows (not quite as pretty because it doesn't have the surrounding header/footer HTML) and still does not work for Apache for Linux.

So yes, I've cut out as much of my own code as possible to eliminate the possibility it's something I'm doing.

There are two possibilities left: 1) there's some setting in FireDAC or WebBroker I have missed that needs to be configured differently when running under Apache for Linux, or 2) I've uncovered a bug somewhere in FireDAC or WebBroker.

Interesting. So, what would that imply? FireDAC's TDataSet requires a TTimer or multi-threading of some sort?

My debugging shows the query is returning records. In fact, I set up a memory table and copied the records there, switched the table producer to point to the memory table but it still shows an empty page. I guess that's not surprising as the problem is higher up, either with the TDataSet or the TDataSetTableProducer.

As another test, I created a console-based Windows web sever using the same data modules, thinking for sure the console wait-cursor would work--nope.

Oh well, this is not a critical issue, more of a curiosity; although I'm now leery of writing Linux web modules...

Lots of good information in this thread but I'll add a blog I wrote a couple of months ago that explains how I use a certificate from K Software (less than $100 year) to sign both Delphi apps and installs built with InnoSetup: 

What can Code Signing do for you?

Perhaps it'll add something useful for someone.

OK, I explicitly, without any conditional compilation, used first just FireDAC.ConsoleUI.Wait then added FireDAC.Comp.UI in separate tests for both Apache for Windows and Apache for Linux.

No errors, no data--from either one.  I change only the first unit (ConsoleUI) to either FireDAC.VCLUI.Wait or FireDAC.FMXUI.Wait and I get a dataset in Apache for Windows but not Apache for Linux.

Here's the section of code from my web action item that tries to get the data set (the database is a list of park names and coordinates):

  try
    try
      Log.Debug('getting park list', LOG_TAG);
      dmParksDB.OpenParks;
      Log.Debug('parks table is open', LOG_TAG);
      Result := dstpMyParks.Content;
      Log.Debug('returning park content', LOG_TAG);
    except
      on e:Exception do
        Log.Error(e.Message, LOG_TAG);
    end;
  finally
    dmParksDB.CloseParks;
  end;
  Log.Debug('parks are closed', LOG_TAG);

Here are the log entries:

2021-06-22 01:11:10:777  [TID 139867211564800][DEBUG   ] getting park list [web]
2021-06-22 01:11:10:791  [TID 139867211564800][DEBUG   ] parks table is open [web]
2021-06-22 01:11:10:791  [TID 139867211564800][DEBUG   ] returning park content [web]
2021-06-22 01:11:10:794  [TID 139867211564800][DEBUG   ] parks are closed [web]

"dstpMyParks" is a TDataSetTableProducer whose DataSet property is hooked to a query in a data module.

I'm using a different web action item to make a simple database query of the same "parks" database and table and it works fine on all platforms.

If you want to see the code, it's on GitHub (still has the conditional compilation).

I am wondering if there is a library file I'm missing. Before I copied libgds.so to the Linux system, the park lookup function did not work--no error, just no data.

Thanks for your suggestions.

Before someone catches my mistake, I just want to point out that the {$IFDEF WINDOWS} is incorrect and would never match because "WINDOWS" is not defined--it should've been {$IFDEF MSWINDOWS}.

Still, I'd like to know how to return datasets from FireDAC on Apache for Linux.

Should.  And I wish but it doesn't in Apache web modules.

Without any conditional compilation, if I use FireDAC.ConsoleUI.Wait, no Apache web modules of either platform will show a dataset result. If I change that unit to either FireDAC.FMXUI.Wait or FireDAC.VCLUI.Wait, then I do get a dataset result but only for the Windows version of the Apache module.

Another interesting note, I expanded the testing with platform conditional directives:

{$IFDEF CONSOLE}
  APP_NAME = 'My App Console';
{$ELSE}
  {$IFDEF LINUX}
  APP_NAME = 'My App Linux';
  {$ELSE}
    {$IFDEF WINDOWS}
    APP_NAME = 'My App Windows';
    {$ELSE}
    APP_NAME = 'My App [unknown];
    {$ENDIF}
  {$ENDIF}
{$ENDIF}

and found something interesting:

• Apache for Linux showed: My App Linux
• Apache for Windows showed: My App [unknown]

So, Apache for Windows modules evidently don't know what platform they're compiling for!

Then neither the Linux nor the Windows versions shows the dataset.  At least the way I have it now, the Windows one works.

Here's my uses clause:  

  {$IFDEF LINUX}
  FireDAC.ConsoleUI.Wait,
  {$ELSE}
  FireDAC.FMXUI.Wait, FireDAC.Comp.UI,
  {$ENDIF}

Here's a constant defined which shows on the generated web page that indicates which platform it's running under:

{$IFDEF CONSOLE}
  APP_NAME = 'My App Console';
{$ELSE}
  {$IFDEF LINUX}
  APP_NAME = 'My App Linux';
  {$ELSE}
  APP_NAME = 'My App Windows';
  {$ENDIF}
{$ENDIF}

The Windows one shows up for Apache for Windows, the Linux one shows up for Apache for Linux.  The Console one, as you might guess by now, never shows up.

So yes, I'm sure the conditional compilation is working as expected.