Quote from luishp on September 20, 2026, 1:00 pm

Yes, there is a cleaner way to do this, and the iFrame itself is not really the problem. The problem is that the iFrame currently points outside the compiled application.

VisualNEO Web's documentation describes the iFrame as an object whose source specifies where its content is located. It also documents a useful mechanism for bundled resources: folders can be included through Project → Properties → Libraries / Files. The neoH5P documentation explicitly uses this mechanism to include an extracted folder in the project.

How I would build it

Suppose SpikeUI exports this:

SpikeUI/
    index.html
    css/
        style.css
    js/
        app.js
    images/
        logo.png

Don't make your VisualNEO iFrame source:

C:\Users\YourName\Documents\SpikeUI\index.html

That works during development because your PC has that exact file. Once the app moves to another computer—or becomes a PWA—that location no longer exists.

Instead, include the whole SpikeUI folder as part of the VisualNEO Web project using:

Project → Properties → Libraries / Files

Then the compiled application should contain something conceptually like:

MyApp-Web/
    index.html
    ...
    SpikeUI/
        index.html
        css/
            style.css
        js/
            app.js
        images/
            logo.png

Now the iFrame uses a relative URL:

SpikeUI/index.html

instead of:

C:\...\SpikeUI\index.html

That is the important change.

When you move or ZIP the application, the SpikeUI website travels with the VisualNEO application. For NW.js this is particularly appropriate: the VisualNEO documentation says the application files are shipped together with the NW.js application/package.

Make SpikeUI's export portable too

There is a second potential trap. Inside SpikeUI's generated index.html, its CSS, JS, images, fonts, etc. must also use portable URLs.

Good:

<link rel="stylesheet" href="css/style.css">
<script src="js/app.js"></script>
<img src="images/logo.png">

Bad:

<link rel="stylesheet"
      href="C:\Users\Bob\SpikeUI\css\style.css">

Also watch for root-relative URLs such as:

<script src="/js/app.js"></script>

For a PWA hosted in a subdirectory, that leading / can unexpectedly refer to the root of the entire website. In an embedded package, I would generally prefer:

<script src="./js/app.js"></script>

There may be an even better architecture

If SpikeUI is mainly generating the visual interface, I would seriously consider eliminating the iFrame eventually.

VisualNEO Web's Container can contain arbitrary HTML; the official help specifically says that any HTML code can be added to a Container, making it useful for advanced applications.

So there are really two architectures:

OPTION A — easiest migration

VisualNEO Page
     │
     └── iFrame
           │
           └── SpikeUI/index.html
                  ├── css/
                  ├── js/
                  └── images/

versus:

OPTION B — tighter integration

VisualNEO Page
     │
     └── Container
           │
           └── SpikeUI HTML
                 │
                 ├── VisualNEO variables
                 ├── VisualNEO objects
                 └── VisualNEO programming

Option A is where I'd start. It requires much less alteration of the SpikeUI export and gives the designer a clear separation between UI and VisualNEO programming.

Once that works, you can investigate Option B for interfaces where you want much tighter communication between the generated HTML and VisualNEO.

VisualNEO also supports communication between JavaScript and VisualNEO actions/subroutines; the manual specifically has sections for Accessing Variables from JavaScript and Calling actions from JavaScript. That opens up an interesting architecture where SpikeUI handles the presentation while VisualNEO Web remains the application's programming layer.

For a PWA, remember that VisualNEO's documentation says the resulting PWA needs to be hosted on an HTTPS-capable web server for normal installation.

So my first experiment would be very small: export a SpikeUI page containing one button and its CSS/JS, add its complete folder under Libraries / Files, change the iFrame source to something like SpikeUI/index.html, build, and then inspect the generated build directory. If SpikeUI/index.html, its CSS and its JS are all there, you've eliminated the C:\... dependency.