Project Mode Conversion

My applications are currently at v18.2 and I would like to move to project mode. Before I do, I have two questions:

  1. Are there any important fixes between v18.2 and v18R3 for the conversion process? I couldn’t find any in the release notes, but wanted to make sure. Basically I prefer to convert while in v18.2 because I can then use branches for working in R-releases which seems safer to me. But if v18R3 will convert to project mode better in some way, then I would consider that.
  2. Have many of you deployed from project mode? I’m wondering about real world experience for deployed applications. Rough edges? Same as non-project mode?

Any insight would be greatly appreciated!

I converted to project mode with 18 LTS. The only change I have noticed between 18 LTS and R3 in git is that forms created or edited in R3 get an additional property:

	"$4d": {
		"version": "1",
		"kind": "form"
	}

I deployed in project mode with 18.2 about 3 weeks ago, no major issues. I originally planned to use 18R2, but saw important bug fixes in 18.2 and 18R3. It is great to finally be able to use git to manage all 4D source including forms.

I did run into one reproducible crashing issue with list boxes (arrays, boolean column) in R2 and R3. But I could not reproduce it in a separate structure after hours of trying. I just gave up and figured out a work around that prevents 4D from crashing.

1 Like

Reading between the lines of this blog post https://blog.4d.com/project-databases-method-documentation-is-back/, it looks like converting in 18R3 will preserve explorer comments on methods and such, where 18.2 won’t.

Thank you, John. I really appreciate this information!

Thanks, Scott, that’s good to know. Luckily I’m not using explorer comments, so that one won’t make a difference. But those are the kinds of things I was wondering about.

John - is this deployment compiled or interpreted?

For information, all internal components of 4D and user components are in project mode. Our internal database also.

Compiled and merged. Local network, all Mac, client/server with 16 users. Roughly, 150 tables, 250 million records, 6000 project methods.

I have another project mode conversion question. I’ve converted a few applications now. One issue I have run into is in the use of OBJECT SET STYLE SHEET. I now get an error when using it:

I suspect this has something to do with the conversion to CSS classes, but I can’t work out how I’m supposed to fix it. Should I not use this command in project mode? Is there a replacement?

Thanks for any insight.

If I were in that situation, I would go back to my copy of the binary database and “export” all stylesheets, perhaps as JSON. I would get my LIST OF STYLE SHEETS, iterate with GET STYLE SHEET INFO. Then, for the short term, I can redirect my calls to OBJECT SET STYLE SHEET to set the font, size and styles directly. That would buy some time to transition to classes.

Tip

Here is how I use css in my forms.

  • 4DForm
{
	"css": [
		"/SOURCES/print.css",
		"../../screen.css"
	],
…

For dialogs on screen, the form is called by its name, so the backend 4DForm file is loaded and the relative path (../../) finds the css file 2 levels up, in /SOURCES/ where I keep my generic css for display, which cascades on top of the “print.css” stylesheet.

For printing, the form is loaded in an object in my code, so it has no “base” path. Only the “file system” path (/SOURCES/print.css) is resolved.

In both cases, the basics sheets (styleSheets.css, styleSheets_mac.css, styleSheets_windows.css) are loaded. That gives me several levels to organise my css,

  1. styleSheets.css
  2. styleSheets_{platform}.css
  3. /SOURCES/{any}.css
  4. /…/…/{any}.css (ignored if the form is loaded as object, same location as #3)
  5. {any}.css (ignored if the form is loaded as object, adjacent to 4DForm)

and their role would be,

  1. application-wide
  2. platform-specific
  3. for print media (or more specifically, for forms loaded as object)
  4. for screen media
  5. form-specific
2 Likes

Hi Miyako,

Thanks for the info. I did check the styleSheets_{platform}.css files and my stylesheets were converted properly. The widgets I’m using OBJECT SET STYLE SHEET on are necessarily created on the fly (OBJECT DUPLICATE to create a variety of widgets).

Are you saying there isn’t currently an equivalent of OBJECT SET STYLE SHEET to set the CSS class for an object on the fly in project mode? If that is true I can probably work around it by directly setting font characteristics as you say. I just need to be clear about the status of the command. Was this just something that was missed or is still in the works?

Thanks.

My understanding is the the development of Project Mode gave the Engineering department an opportunity to reevaluate long-standing specifications in 4D. Features that were based on obsolete concepts, redundant, contradictory, obsolete, short-sighted, or not future proof for any other reason, were heavily scrutinised, balancing the cost of emulating (and maintaining) the old behaviour using new APIs, versus investing in an alternative feature that was more sustainable.

The stylesheet feature was problematic from its start, it was a basic font mapper for Mac OS 7 and Windows 98, that’s all. It’s handing of font metrics and DPI across platforms have issues, it’s not a real “style” sheet, it doesn’t handle font substitution, and so on.

So no, nothing is “in the works”, stylesheets are for binary mode only.

1 Like

Thanks, Miyako. That gives me the info I need to move forward.