Does anyone deploy SDI applications?

Hi everybody,

I’ve searched through the forums and there are not a lot of posts concerning SDI mode for Windows. So I wanted to ask if somebody is actually deploying applications with the SDI mode activated ?

We did some internal tests, and we have a couple of issues with this mode, especially for windows positioning and resizing according to the task bar (we already created TAOW cases for these).

We have problems with menu bars as well (not drawn in particular cases), and so on.

Can you please share your experience with SDI if you use it and tell me if you’re facing problems too ?

Maybe we can help each others. :wink:

Thanks in advance.

Regards,
Lionel Leeser

Hi Lionel,

I used DSI mode for windows and engined application.
I don’t use menu but have an issue on buttons bar (taow opened)

Patrick

Hi Patrick,

Yes I read your posts on the subject.

That’s one more. Maybe the fact that SDI is not available in design mode make the tests more painful for 4D and sadly the feature feels like it could deserve more intention.

But for a feature that is already more than a year old, it is surprising to see that so few people use it and experimenting with it in real cases.

I hope I’ll get more answer on this thread.

Regards,
Lionel Leeser

: Lionel LEESER

But for a feature that is already more than a year old, it is
surprising to see that so few people use it and experimenting with it
in real cases.

SDI mode, is not just a simple feature, not a check box feature.

While it might look like “just click a check box, finished”, in real live, it requires a total rewrite of the user interface of an application. And not just technical rewrite, also a redesign of user interface, of how to use the application.

Just take a look on the process of Microsoft Office in the last 10 years. They did not simply changed, they did it application by application, with Outlook last.

If your application handles isolated documents, like text files, SDI mode is easy to implement.
But if you handle complex processes, like an ERP system, you cannot simple open another “instance” (read document or read window).

And, again Microsoft Office as example, the concept of a menu bar needs major thinking. Microsoft decided to switch to “ribbons” to solve this. And I assume you remember the very emotional discussion for Office 2007 when this started.

So, for a 4D app, this means, don’t use menu bar any more. Don’t use a general “tool bar” anymore (use more ribbon like included tool bars in the window itself, not a main one on top of the monitor).
Redesign the application to follow the concept of instances, like Microsoft Word.
Or find another way how to redesign.

Whatever you want to do, it is a huge interface work (followed by coding and customer training).

Feature is a year old? So what? I think that will take - similar to Office - most professional developers a similar time - that could be 10 years.

For the internal application we use in Germany, i tried the instance concept.
On startup I open one window. That window can display customers, or invoices, or licenses, the user can switch. Everything in that single window.
The user can open another window. This is a kind of another instance. It can also display customers or invoices and so on. Another one? Why not. Similar as Word can open another document. Each “instance” is isolated and work on its own - but support drag&drop between.
But it usually are 2 windows. Sometimes 3. Not more. Else the user will be confused and “searches” the windows. Reminder, with MDI, if you click on one, all comes back to front. With SDI, only the clicked one comes to front. So you could see a 4D window, behind an Outlook window, then a 4D window, then everything else covered by an Excel window (with more 4D windows behind). Simply moving to SDI does not work. The application needs to be redesigned to reduce the number of working windows…

That concept worked for us quite well and was not difficult to develop. Was it the best idea?
Don’t know (yet)

Outlook is another approach.
It would be one window to handle the main application.
Like on the left a list allowing to switch between invoice, customer, etc.
Next to that list another list box showing a list of invoices, customers, etc.
And on the very right, a preview area.
Whatever record is selected, here we show the details of this record.
To do so, we could imagine a subform, where the content (input form) is changed when the user selects another table. It would even allow to edit.
Then the user double click a record in the list, another window is opened, a window only for the detail form.
Very different concept as “instances”, following the concept of Outlook (mail list - preview or double click for full window). This gives “only” one list, but many input windows.
Is that better for the end user? Don’t know, but looks interesting.
Before that would be difficult to code, with ORDA it would be much easier, all could even be done in a single process.
I like that idea a lot and wish I could find the time to rewrite our internal app just to see that in action, to see how the end users would like it. I think that has potential.

Enabling SDI is not the problem. Creating an application helping the customer to be more productive, that’s the challenge.

At least I see it like that.

First of all that’s a great answer. Thanks a lot for that.

Of course the transition to SDI can be painful for a lot of developers and I totally understand that. But in our case we are well aware of the implications of SDI versus MDI and have thought a lot about it. And we cannot stand the old XP look anymore.

On a basic level, SDI is how all Mac applications work and is not such a radical change for us, the difference being that the main menu bar in SDI is in our main window instead of the top of the screen. All our entry form windows can share the same basic menu bar, and all modal dialogs like alerts don’t need a menu bar at all.

So we know what we want to achieve, but we can’t do it if the few remaining bugs we have reported aren’t properly addressed by 4D.

But with that being said I really hope that the SDI will gain in popularity through the 4D community and make it evolve by experimenting with it.

Regards,
Lionel Leeser

1 Like
: Lionel LEESER

On a basic level, SDI is how all Mac applications work
:?: :!: :doubt:
On Mac there is only one menu per application, no one menu per window ?

The other MAJOR problem is that with SDI on PC you have to do special code (PC only) for that; so the code is no more multi-platform… :frowning:

Hi Manuel,

: Manuel PIQUET

On Mac there is only one menu per application, no one menu per window ?

Of course, if you read my answer a bit further I talk about how we attend to manage menu bars.

: Manuel PIQUET

The other MAJOR problem is that with SDI on PC you have to do special
code (PC only) for that; so the code is no more multi-platform

That’s true ! At least we have access to nice commands to check the current platform we’re on :

https://doc.4d.com/4Dv17R4/4D/17-R4/Is-Windows.301-4054994.en.html
https://doc.4d.com/4Dv17R4/4D/17-R4/Is-macOS.301-4054995.en.html

:lol:

Regards,
Lionel Leeser

: Lionel LEESER

On a basic level, SDI is how all Mac applications work and is not
such a radical change for us, the difference being that the main menu
bar in SDI is in our main window instead of the top of the screen.
All our entry form windows can share the same basic menu bar, and all
modal dialogs like alerts don’t need a menu bar at all.

I’m sure you already deeply investigated and know about this, so the following is more for others’s new to SDI…

on first view, SDI looks similar to Mac. I myself thought that it would be easy, as, yes, I started with Mac many years ago.

First version just needed an hour. After I deployed, I quickly switched back to previous mode.

On Mac, you have that one single menu bar always available.
On Windows SDI, each window could have a menu bar. That’s not really the same.

In my very first try, I had many windows without menu bar. Then I realised that copy&paste was not working (and some other features not in my toolbar, only in menu).
So I thought, simple. For second try, I just change my open window wrapper and make sure I always have a menu bar.

Again, fast coding, fast deploying, fast going back.

It looked great on first view, but then I realised that many simple dialogs, like my own Query dialog, have a menu bar. Even my own alert.

Now I finally understood, I really understood, that a window is not a window.
I needed to build groups. Main window (where data is displayed). Tool windows (like Query, Order, similar editors). Alert windows, and so on.
And they need to be handled differently, something I never cared on Mac (or Windows).

That’s why I wrote originally, I took much more time thinking about user interface, then coding.
After I found a way how to handle it in our workflow, it was simple (for coding). And it was simple in the following year, once correctly designed, I don’t need to think about it anymore.

Hi Thomas,

thanks a lot for sharing your experience.

My concern is about the “tool bar”, like it is establish in 4D. This specific dialog is today for the full application on OSX but not on Windows system where a ribbon is used, and like you explain also in a previous message.

It would be great to be able to define, dependly of the operating system, the way to use this kind of dialog. Are you working on this way and for which timeline?

Again, I understand perfectly that it takes time for you to migrate but also for us, and more, both, we are late, less we’ll be able to deliver applications with this “old new design approach” :wink:

Patrick

no, I - at least I personally - don’t believe that a generic toolbar on top of the monitor is the good way to work with SDI applications.
I’m not aware of any application on the market working like that, do you have examples?

On Windows SDI, it seems (following Microsofts examples), a window specific “toolbar” is the right way to go.

This means, on each “main” window (not in dialogs), you use the top part of the window to include that. This works fine in 4D with inherited forms.

It could just be several buttons.
It could be groups of buttons, which resize/reposition automatically depending of available space.

Whatever it is, it is not one toolbar on top of the screen, as on Mac, it is one toolbar per window.

So it is not the same. Not the same content.
If you have one generic on Mac, this toolbar could include elements to control all windows. With a window specific one, the content will be different.
Beside, on Mac it is standard to have a menu bar, so some actions will be in menu, some in toolbar. On Windows it is often different.
You might want to take a look on Office Mac and Office Windows. Use for both the current version (Office 365), don’t compare older ones. This could help to get ideas.

So the big question you need to ask yourself, will this toolbar on top of the window replace the menu bar, so you don’t use menu at all (as Office or other applications are now doing on Windows, while they still have menu on Mac, with different toolbar content Mac/Win) - or do you use both, menu and toolbar. That’ up to you.

Hi Lionel,

The way you describe how you work is exactly the way we work
In the near future we are going to deploy our multi-platform application in SDI mode on Windows
We have 1 toolbar, and on every “main” (hundreds) window we have a menu bar
For now we don’t care if this good UI design
The only 1 thing we care of is that when maximizing a window it gets under the toolbar, as is the case on OSX
Unfortunately, because of the UI vision of 4D (and maybe the rest of the world, other than the two of us), I am afraid there will be done nothing about it