First impressions, thoughts and some questions

[StephenLeibowitz]

If the command line option was implemented, it would be possible to use it for a Web Connect facility. This post describes how it might work in Windows.

For QIF imports, add this batch file to the same drive as the mmex program. A similar batch file could be used for CSV:

Code: Select all

:: The /IMPORTQIF option is not yet implemented.
cd \Program Files\mmex-1.6.4-win64
:: Running the following START command should display the
:: “Import from QIF file” screen with the File Name field
:: populated with the parameter to this batch file.   
START "MMEX" bin\mmex.exe /IMPORTQIF %1

The use of an IMPORTxxx command-line option would be easier if the MMEX Instance Check was changed. My thinking is that if the requested database is already open in an MMEX instance, the import should be for that instance.

For Chrome users, associate the QIF file extension with the batch file. See Associate file extension with an App in Windows 10.


For Firefox users: Settings > General > Applications > Content type (QIF) > Action > Use other... (the batch file)

From the financial institution website, download the QIF file to import into MMEX. For Chrome users, In the bottom left corner of the browser window, click on the ^ next to the QIF file name. The following pop-up menu should appear. Click on one of the first two items:

Open
Always open files of this type
Show in folder
Cancel

[MartinArmstrong]

:: Running the following START command should display the
:: “Import from QIF file” screen with the File Name field
:: populated with the parameter to this batch file.

You can achieve this right now by simply dragging the .qif or .csv file onto the account's transaction list.

[StephenLeibowitz]

Martin Armstrong’s approach has merit, but I think it largely comes down to personal preference. And it is not unusual for an application to have more than one way to accomplish something.

There are some disadvantages of drag and drop. You would need to have the two windows visible on the screen. This might require moving or resizing one or both of the windows. Also, some pointing devices are less suited to DND than others.

Here is a quote from the Nielsen Norman Group:

The downsides to drag–and–drop are that it can be inefficient, imprecise, and even physically challenging, especially over long distances: if they run out of room, users might need to reposition their mouse or adjust their finger on a touchscreen. Thus, it often results in errors — the user drops an item in the wrong spot, and has to start all over again.

Firefox users would have to open a File Explorer window and navigate to the downloaded file before dragging. Browsing from the MMEX Import from menu item would usually be easier.

[MartinArmstrong]

It is not unusual for an application to have more than one way to accomplish something.

MMEX currently has:

1. Menu 'File | Import from | QIF (or CSV) Files'
2. Right click on an account in the Navigation tree and `Import from | QIF (or CSV) Files'
3. Drag and drop QIF (or CSV) file on to a transaction list.

You can even drag and drop multiplefiles on to a transaction list and MMEX will do the QIF or CSV Import for each file, one after the other.

There are some disadvantages of drag and drop. You would need to have the two windows visible on the screen. This might require moving or resizing one or both of the windows.

It is not necessary to have two windows visible on the screen or move or resize them.

1. Start MMEX and make sure you are displaying a transaction list.
2. In File Explorer (let's assume it is maximised so it completely hides the MMEX window) you now can highlight your QIF or CSV files and drag them over the MMEX icon on the taskbar, hover there for a moment and the MMEX window will pop up. Now drop the files in the transaction list.

Hovering files over a taskbar icon to pop up the relevant (running) application has been standard Windows functionality since 2009.

Also, some pointing devices are less suited to DND than others.

Maybe. But honestly I haven't experienced this.

I use the trackpad on my laptop rather than a mouse almost all of the time and have no problems doing drag and drop.

I've also tested it with a touch screen and I find it is OK there too.

Firefox users would have to open a File Explorer window and navigate to the downloaded file before dragging. Browsing from the MMEX Import from menu item would usually be easier.

Sorry, but this is just not true. The user does not need to "open a File Explorer window and navigate to the downloaded file". Just use the facilities provided by Firefox (or Chrome, Edge etc) to directly open File Explorer with the downloaded file highlighted. It takes just 2 clicks as shown and then you can drag the file straight into MMEX.

Firefox download.png

I'm not dismissing your idea but I am trying to show that it's not at all difficult to download a file and quickly import it into MMEX without having to make changes to MMEX command line parsing, the MMEX Instance Check, and file associations.

[nstein]

I second to the feature of:

Hm. It should be possible to add custom fields (after definition) to the import fields. Noted.

I have added custom fields to CSV import for version 1.7.0.

[alas]

I have several scheduled transactions. I like to enter them all for a year ahead. At the moment I have to click on each one and then click enter before moving on to the next one. This is tedious. I would like to be able to tell the software to enter all scheduled transactions for the next month with one click.

I did raise this some time back and received the amazingly helpful comment: ' Why would you want to do that?' Well, I do want to do that.

[whall3y]

Please raise a feature request here ... https://github.com/moneymanagerex/money ... .md&title=

[nstein]

I have several scheduled transactions. I like to enter them all for a year ahead. At the moment I have to click on each one and then click enter before moving on to the next one. This is tedious. I would like to be able to tell the software to enter all scheduled transactions for the next month with one click.

I did raise this some time back and received the amazingly helpful comment: ' Why would you want to do that?' Well, I do want to do that.

@alas Scheduled transactions have a lot more flexibility than most people realize.

You can set them to enter automatically ahead of time. Note that "Date Due" is the date when MMEX will enter the scheduled transaction. The "Date Paid" is the transaction date that will be used in the details of the next transaction. Whenever a scheduled transaction is entered, MMEX automatically increments both Date Due and Date Paid by the setting you have chosen in "Repeats".

For example, if you want to schedule a transaction to be entered one month ahead set the "Date Paid" one month after "Date Due", or if you want to schedule a year ahead of time set "Date Paid" to 1 year after "Date Due", etc. Then click the checkbox that says "Grant Automatic Execute".

So if you set "Date Due" = 2024-04-01 and "Date Paid" = 2024-05-01 and Repeats = Monthly, then on April 1st MMEX will automatically enter the transaction for May 1st, then it will automatically update "Date Due" to 2024-05-01 and "Date Paid" to 2024-06-01. On May 1st it will automatically enter the June 1st transaction, etc.

You can even enter a full year's worth of transactions automatically. Set "Date Due" to 2023-04-01 (note this is 12 months in the past) and "Date Paid" = "2024-04-01" with Repeats = Monthly and Grant Auto Execute. When you restart MMEX it will enter 12 transactions dated "2024-04-01" to "2025-03-01". Your next scheduled transaction will then be "Date Due" = 2024-04-01 and "Date Paid" = 2025-04-01.

Maybe that will alleviate some of the tedium.

[Simon1D]

That's a really nice feature, which will improve the usability of mmex for me - thanks for explaining how "Date Due" works, @nstein - I never used that feature, and tbh never saw the point of it, which is much clearer now. (I think I might have been blind-sided by the built-in dashboard feature Upcoming Transactions, which lists transactions which are scheduled in the next 14 days but which haven't yet been entered. (It disappointed me that "14 days" doesn't seem to be user-configurable.)

More generally, this makes me wonder what other neat features of MMEX might be hiding in plain sight, underappreciated by users like me (and I've been using it for over 10 years).

In the absence of anyone who knows MMEX inside out (and so understands how to use it effectively) having the time to overhaul the documentation, perhaps the best we users can do is offer little narratives describing how we use MMEX in practice, in the hope that this prompts more observations like this. There must be a fair few such things already on this forum - I need to read more ...

[Renato]

In the absence of anyone who knows MMEX inside out (and so understands how to use it effectively) having the time to overhaul the documentation, perhaps the best we users can do is offer little narratives describing how we use MMEX in practice, in the hope that this prompts more observations like this. There must be a fair few such things already on this forum - I need to read more ....

From my point of view, this is absolutely correct, the descriptions are completely outdated.
I also have trouble understanding all the functions that have been implemented.

Our users have many good ideas and if the developers are happy with these ideas, they are usually implemented in the post. Unfortunately, it is forgotten that these changes/extensions should also be documented. Of course, this makes MMEX much more useful for a few individual users, but unfortunately the vast majority of users can then benefit little or nothing at all.

When I programmed my first dialog-oriented accounting system in 1977, I was faced with the same problem. The specialist departments (such as accounting) made many requests, which I was then able to implement with many sessions. But as a developer, I lacked the necessary expertise to create self-explanatory documentation. I then turned the tables, when the specialist department had documented the necessary additions in the manual, I then implemented these features.

I could imagine that this could be handled in a similar way for future improvement requests.
The user completes the documentation (in English) and then a decision is made on implementation.
Of course, this does not solve the existing problem of documentation, but perhaps a few users can be found to help improve the existing documentation.

But despite the lack of documentation, I find MMEX to be a very helpful accounting system, even for beginners/laymen, and it's free to use.
I still think our developers are doing a great job.
A big thank you certainly also belongs to @guanlisheng , he has brought the Android version back up to date.

I'm sorry if I'm getting involved in this as a moderator.
I look forward to hearing your views on this post.

[Simon1D]

... I then turned the tables, when the specialist department had documented the necessary additions in the manual, I then implemented these features.

I could imagine that this could be handled in a similar way for future improvement requests.
The user completes the documentation (in English) and then a decision is made on implementation.
Of course, this does not solve the existing problem of documentation, but perhaps a few users can be found to help improve the existing documentation.
...

Agreed.
It's a much bigger context, but your comments remind me of the way Python evolves, in large part driven by PEPs (Python Enhancement Proposals), which are openly discussed and debated quite a lot before being finalised, never mind implemented and released (or rejected).
The existing documentation of MMEX is somewhat monolithic, and the idea of revising it is a bit daunting. I wonder - could improved documentation come into being through a collective effort to build a wiki, initially focused on ways to use MMEX?