Xeffort site to be archived

[Steve_Lionel]

Back in 2007, Jugoslav Dujic, whom long-time members here will remember, created:

Xeffort library (previously known as XFT) is used for easy building Win32 GUI applications with Compaq and Intel Visual Fortran compilers. It seamlessly integrates with Microsoft Visual Studio (.NET) IDE providing:

• Application wizard, for quick creating of skeleton MDI, SDI or dialog-based applications

• Handler wizard, for creation of prototypes of most-frequently used routines

• Online help, which can be run from Visual Studio "Tools" menu

He made the library and its documentation freely available as open source. In 2013, Jugoslav handed over the Xeffort site to me, and I made it available as xeffort.info, where it sits today.

Unfortunately, the code is highly bound to the 32-bit architecture, so is unusable with today's Intel Fortran. I did spend some time a few years ago to try to update it to 64-bit but found it overwhelming as there was too much hardcoded for 32 bits.

My intention is to take the xeffort.info site offline, but at that point I'll keep the files available in a folder under stevelionel.com (there will be a redirect for a while).

If someone wants to take on updating Xeffort for 64-bit, feel free to download the sources and have at it.  Someone did contact me some years back offering to do this but did not follow up.

I think the library is valuable and would prefer to see it live on.

[Steve_Lionel]

Regarding the "little beauty", have a look at Doctor Fortran in "Think, Thank, Thunk" - Doctor Fortran where I once encountered something similar.

[Steve_Lionel]

Maybe Serial Port I/O Library Routines

[JohnNichols]

Of course, so sorry.  

I have a new accelerometer, it will output 800,000 records in 100 seconds, way too fast, but the manufacturer cleverly put in a compression format on the output so you have to use Python or their special purpose program.  

I asked for the compression algorithm so I can use Fortran and do FFT and other nice things quickly.  

Am I allowed to say that Python is not a good program. 

[Steve_Lionel]

John, please start another thread on your topic.

[Steve_Lionel]

Today I learned about The Winteracter Fortran GUI Toolset is now available free of charge - Announcements - Fortran Discourse - this is, I think, much better than QuickWin. The only advantage to QuickWin I can see is that it will allow Fortran I/O directly in a Window.

[DavidWhite]

Unfortunately, another of a string of Window's libraries which is no longer supported.

I started with RealWin, when that went out of business, I swapped to XEffort, and then to Winteracter, which I have used for perhaps 10 years very successfully.  I no longer maintain the software that uses Winteracter, but have kept up a license just in case.

Lawson was very supportive when Winteracter was a commercial product, hopefully we can continue to get good use out of his library.

[Neels]

I have two pre-processors (modelers) and two post processors (mostly graphing) done almost exclusively in QuickWin and is altogether about 120 dialog boxes with many of them scrollable and the extra functionality I needed is through Xeffort. Upwards of 600k lines of code and almost 30 years of work, as much as I would prefer to change over to Winteracter it is just not worth it.

I am hoping Andrew will get Xeffort converted to 64bit to the point where I can use it.

[andrew_4619]

I haven't worked on that for a while, been far too busy with some other projects. However, all the examples I have looked at have been xeffert applications not QuickWin. I used to use QuickWin many years ago but found it too limited  and ditched it in favour of just using he windows api. That said I am interested in what features of xeffert you are applying to enhance Quickwin? Dependant on this answer to that there may be some simpler solutions to your problems.

[Neels]

Andrew,

The biggest part I use is the Xeffort tool that creates a dialog based application.

Then most of the rest was what Jugoslav did when he edited IFLOGM to create XFLOGM. One of the biggest things I use is fairly simple:

Using XFLOGM:  RetLog = XCtlSet (ml2Dlg, IDC_STATIC_Passage, .True., Dlg_Visible)

Using Xeffort:  RetLog = XCtlSet( ml2Dlg, IDC_STATIC_NozzleDiameter, .True., Dlg_Visible)

And then some minor things like XMessageBox which is easier to use, it does not use C strings etc.

Jugoslav also showed me how to make the dialog boxes scrollable if they are bigger than the screen.

I can send you samples if you want.

Thank you,

Neels

[andrew_4619]

Neels those seem like quite simple things, a simple helper routine using  the sdk showwindow would fix that and could be inserted with a global edit. Simillary an sdk  message box wrapper replaces the Xmessagebox.  do you have a full list of "X" routines that you call?

[Neels]

Andrew,

Thanks for looking at this!

I am not sure when I use XFLOGM and when I use Xeffort, so I made a short document showing what I do. I see XFLOGM was a modified version of DFLOGM from the DEC days.

Thank you

Neels

[andrew_4619]

Just noticed this, I will have a look at it.

[nathn34]

Hey Steve,

I totally get where you’re coming from on this. Legacy tools like Xeffort usually sit in that weird space where they’re still valuable but the tech stack underneath just ages out. I’ve faced something similar with an old Win32 utility toolkit I was maintaining a while back — once 32-bit dependency hits hardcoded levels, porting to 64-bit basically turns into a full rewrite more than an update.

What worked for me was first documenting everything properly before even thinking about migration. Second, splitting the core logic from UI layer (that’s usually where the 32-bit mess hides). And third, just seeing if anyone in the community actually uses it today before investing time.

Honestly, if you’re moving it under stevelionel.com, that’s already a solid preservation step. In my case I had a small internal repo under CodeNest just for archiving old tools.

Do you think there’s still active demand for it, or is it more of a “preserve for history” situation now?

[Steve_Lionel]

I don't think there is a demand for Xeffort, besides a few applications previously developed using it. It probably would be worth someone's while to make it work in x64. I will preserve it, nonetheless. Really, the only ongoing expense to me is the domain name.

[Neels]

Thank you Steve.

I could never understand why the few edits Jugoslav did to DFLOGM to create XFLOGM was not implemented by DEC/Compaq/Intel. For me it greatly enhanced QuickWin.

[cean]

I have downloaded the 1225.exe and installed . There is a lib folder and source folder. But I think from the help file, the source is only the lite version . There is no source for the whole lib.

[Neels]

Extract it to C:\Program Files (x86)\Xeffort

In the root folder there are pictures of what lines to add to the compiler "include" and "library" options.

[cean]

Ok. I saw the project file. Can open it with vs and change to sln file.

I only have ifx, with x64, it has close to 200 errors. Would be nice to upload it to GitHub.

[Neels]

That is the problem with Xeffort, it is a 32bit library.

[cean]

Mang errors are about string operation. Like xc2f-convert string from C style to Fortran style. Instead of calling this function, change to trim the string and add chr(0) at end directly. This reduce 30+ repeat error.

[Steve_Lionel]

The string errors are trivial issues compared to the frequent use of 32-bit INTEGERs to store Windows handles.