Multiple Selections in the Project Outline

Posted: October 28, 2013 | Author: | Filed under: General | Leave a comment

For quite some time, users have been requesting the ability to select and move multiple files within the Project Outline.  This limitation has been present In Simply Fortran from the beginning because Simply Fortran is using Windows’ TreeView control to display the project tree.  The single selection limitation is part of this control itself.

Probably the oddest detail of this restriction is that it appears Microsoft, at some point, was working towards allowing multiple selections.  If you examine the allowed styles, there is a TVS_EX_MULTISELECT style with the not-so-helpful description “Not supported.  Do not use.”  While some might be instantly annoyed with their decision not to allow such operations, there are valid reasons for doing so.

Trying to work out how multiple selections should work becomes complicated almost instantly when thinking about the tree paradigm.  What nodes should be allowed to be selected together?  Can a parent and its children all be selected?  What if you select a parent? Would that imply that its children are selected?  How would Control-A work?  There isn’t a particularly good way to make multiselection work in all these cases, and it probably helps to explain why Microsoft simply chose not to allow it.

To address users’ requests, we’re moving ahead with providing mutliple selections using the mCtrl library.  Simply Fortran already uses a number of mCtrl’s components throughout the development environment, so replacing the Project Outline with mCtrl’s TreeList shouldn’t be overly painful.  In fact, most of the work is already complete.  However, it doesn’t yet support multiple selections.

You can follow progress of adding multiple selections to the TreeList over at GitHub.  Version 2.5 of Simply Fortran should finally allow selecting multiple files and/or folders, along as they all share the same immediate parent.  This selection restriction seems to be a reasonable compromise in order to fit the paradigm.

Constructing import libraries

Posted: October 3, 2013 | Author: | Filed under: Tips and Tricks | Leave a comment

A user just posted an excellent question/bug to our user forums.  Basically, the user was attempting to link a DLL to another DLL created by Simply Fortran, and there were some issues related to the linker finding the first library.  The user was attempting to have the linker automatically find the DLL for linking, and Simply Fortran wasn’t cooperating.  He used the prescribed linker flag -lone to specify that the library libone should be linked to in his second project, but the only product of the libone project was libone.dll.

The resolution was to create a true import library in the libone project.  An import library will just contain a listing of the exported symbols available in the shared library, libone.dll.  Currently (as of version 2.3) Simply Fortran does not automatically create import libraries when building DLLs, but it probably should do so in the future to make everything easier.

In the meantime, creating an import library is still pretty straightforward.  In any DLL project, you can instruct the linker to output a GNU-compiler-compatible import library by adding a flag under Project Options.  In the image below, I’ve already done so:

Project Options dialog

In the options, I’ve set my Target Name to libone.dll as I described earlier.  Under Project Flags, I’ve also added an additional flag to the default flags set up by Simply Fortran:

-Wl,–out-implib=libone.dll.a

The flag above is simply asking the linker directly (hence the -Wl, prefix) to generate an import library named libone.dll.a.  When I clean and build my project, I now should see libone.dll and libone.dll.a in my project’s root directory.

To use this import library in other projects, I now need to use a slightly different flag in the linker options.  If I were linking to a static libone.a library, the flag -lone would be sufficient.  In this case, however, I want to use libone.dll rather than statically linking to an equivalent library.  Therefore, if I’ve created my import library as described, I would instead use the flag -lone.dll.  Now the linker will load and link to libone.dll.a, but the resultant project will require and use libone.dll.

The important bit of information that came out of this bug report is that Simply Fortran probably should handle creating import libraries automatically.  Most every other compiler package on Windows does so in order to make life easier for users, and we of course want to do the same.