Whatever did the trick for .wasm should also have worked for .dfm. Are you sure you’re still getting the same errors, including the 404? if you manually point the browser to the location of the .dfm, does it show in the browser?
The format should not mater for this. That said, yes, the .dfm should be converted to binary code during compile, as I recall (my colleague will weight in). Sure you are uploading the .dfm form your Bin folder, not the one as it is in your project? is it in the Resources subfolder next to your .wasm?
Yes, the code in DelphiVCL will read the dfm and create the HTML controls.
Oh, and also: what version of Elements are you currently using?
Have you checked that the DFM is included as a resource?
If you right-click the DFM file from inside water/fire, there should be a popup-menu with “build action”. Make sure this is set to “resource” before you compile.
mime type: dfm = application/dfm is set. Should it be dfm = text/dfm or some other setting.
I did finally notice the \VCL03\Sample\bin\Debug\WebAssembly\wasm32\resources directory containing TFORM2.dfm which has been compiled. I put it on my site in the wasm folder. It still did not run. where should I put the TForm2.dfm file? Should I rename it the original source file name, unit2.dfm?
We seem to be mixing a to of different issues here.
What’s Unit2? Can we get the existing sample with Unit1 to work via IIS first? That one you said worked in the debugger from Water, so lets get that part reproduced in IIS first, before adding more complexity to the project.
That said, you should not need to do anything with renaming or converting these files, just deploy the files that the build generated. For your own project, with Unit2, make sure there proper build action is set, that will make TFORM2.dfm be created during build…
Can you check to be sure you can access there .dfm files in the browser without getting a 404, and that they are in a “./resources” subfolder next to your .wasm file?
Also, what version of Elements are you using.
Finally, please note that the VCL/DFM support is a highly experimental preview features, and not representative of WebAssembly support in Oxygene in general. It is bound to be very flaky for now, and to properly evaluate Oxygene and WebAssembly, I recommend to focus on non-VCL projects first.
unit2.pas, unit2.dfm are the original files & names in your example link:
unit2 files work in the debugger.
TFORM2.dfm is created during build.
do I need to put a /resources folder in the /wasm folder & put the TFORM2.dfm file in it?
I do note that in the debugger, where it works, there is a noticable delay before the components display which does not occur when the components are in HTML5/CSS. If that can’t be avoided, maybe I can create an HTML5/CSS spinner so user knows it is building page & turn spinner off after VCL load? Any ideas?
I will experiment, but if you guys have advice, I’d like to have it.
The components are on a background image which lays out several separated “Panels” on which the components are placed by category. The Panels are the background image & I place components on them, e.g. Labels, etc.
Can I have wasm/VCL use that background, created by HTML5/CSS, or
Should wasm/VCL load the backgound & put the controls on it, or
IT WORKED! IT WORKED! It needed the /resources folder (actually, to be safe I have a /resources & a /resource folder & don’t know which one was correct, but I’ll find out.
ALSO: The components came up fast, unlike in the debugger. Forget the spinner query earlier.
You guys are great. I’m now going to try to build my actual Ap with WASM/VCL. IF all works, you have another customer. I gotta run the expenditure by my partners, but I believe the advantages will be clear to them (they are not techies).