Unfortunately I’ve already tried that more than one time.
And I tried again now deleting both folders.
The problem is still there on both pc’s: no search text field and duplicate “mine” and “search” bins…
Since I’m a computer developer, I’m now trying to download the source files from git and compile them so I can see the bug from “the inside” Unfortunately this process is not very straightforward, I can compile the software inside QTCreator, but the program crashes at startup…
Yes compiling from source is a challenge. I have a linux system that I’m trying to come up to speed on development on, but there are issues. As Sublimeartistry suggested QT version 5.6 is the place to start as it is the version the .9.3b was built with. I assume you have found the build instruction on
There is also an issue in the llibgit2 release, 23.4 (already fairly back level) doesn’t work properly, I’m going to go back to 23.3 and see if that helps (and then try and move forward towards a more current release). We are trying to get development back on track (and being able to build successfully would be a good start ) so more people doing development is desirable. That said I’m surprised that Win7 is giving problems, I have .9.3b on 3 different Win7 machines (2 64bit and one 32bit) with no issues and we haven’t had complaints in a few months. Win10 has had patching issues in the past but Win7 has been stable. One common problem is not waiting long enough on initial startup. The first thing Fritzing does is get the parts updates from github and it appears to hang (as there is no progress bar displayed). If you interrupt that, it usually corrupts the database and you need to delete the directories and start again.
Yes I’ve followed the build instructions and it builds, but does not run as it crashes at startup (pls see Run inside QTCreator ).
I can confirm that on my win7 64 bit I have this same issue, the same as in the win10 64bit machine.
And I’ve not interrupted the updates from github.
Yep, I saw that thread. Its likely that changing down to QT 5.6 will help (at least that works on Ubuntu 16.04 desktop linux) but as far as I know you are the first (at least lately) to try Windows so you are blazing new ground. The head of the dev tree was broken due to a new gerber implementation which I think has new been reverted. There is a checkpoint at the .9.3b release, but it didn’t work any differently when I tried that on Linux (the same parts update issues occurred which is why I think that is a libgit2 version issue). As noted building a release which gathers all the libraries together fixes that problem, but I’d rather have a working version in QT creator to use.
I’ve resolved the issue!!! It’s a “case sensitivity” problem.
Long story short, the program compares the filename of the selected bin to some “special” names, including the search bin. But the drive letter is lowercase in the “SearchBinLocation” variable and uppercase in the bin->fileName(), so all the “compares” failed!!!
This issue exists all over the source code, not only related to the search bin. Maybe it’s causing other issues other than the missing search field.
Now I want to find an elegant way to solve the bug.
Unfortunately I still have the problem that at each startup some bins get duplicated…
Inside the windows registry, where QT saves application settings, those duplicated bins are actually duplicated inside the “bins2” registry key…
I thinks that also this problem could be caused by some case sensitivity issues somewhere in the code; unfortunately the codebase is big and I’m not familiar with it…
Is it possible that you have an odd setting on your machines that is enabling case sensitivity when it isn’t normally on? Otherwise this bug should be hitting everyone that runs Windows and it isn’t, most people run the binary without problem. I do know of a similar problem but it is the other way, works on Windows but not on Mac or Linux. If the case of a svg filename in the fzp file is different than the case of the file in the file system Windows works (because filesystem case is preserved but ignored otherwise) but on Linux (and I expect MacOS too) the part fails because filename case matters and it can’t find the svg file. It would be good to clean up the code but as you say it is likely to be a lot of work. Hopefully you will like Fritzing once you get it working because we could sure use more people that can help develop, so if we can help just ask!
I understand what you say; I’m one of the few on windows with this problem. Reading other pertinent topics on this forum it looks like that for other people this problem appeared after a windows update. So maybe that’s why some people has the issue and some other do not have it,
By the way, the two pc’s with the problem are completely different: the win7 one is my “work” PC, installed a couple years ago by a corporate technician of the company I work for and I cannot modify any setting on it, while the win10 pc is my pc and I’ve installed it one year ago more or less.
The only difference of the path Fritzing compares is the drive letter, the rest of the path is correct.
and in that page search for “QString QFileInfo::absoluteFilePath() const” (no quotes of course): it’s the method used by Fritzing to get a bin’s path; it says that the absoluteFilePath() methos on windows always capitalize the drive letter; since Fritzing uses the QTString::compare(…) method with no case sensitivity parameter specified, the two paths it compares are different.
I don’t understand why other people are not having the issue
which is the official release site (and where I got mine). If you got it from somewhere else that may be the issue (not that I know it is available from anywhere else, but it may be).
On my working Win7 machine (I have the files redirected off the system partition which is why the f:) the bins show as
Finally I’ve tracked down (is that correct english ?) the issue, I think it could be merged into git.
first of all take a look at the following (closed) QT issue
even if the issue has been closed, you can clearly see that in some cases under windows there can be inconsistencies is the drive name to be upper/lowercase.
To “happily” solve the issue I’ve changed a coupèle of lines in folderutils.cpp from:
I take it something about the order of the calls does the necessary changing the case of the drive letter so the compare works? An alternative would perhaps be to use the toupper() or tolower() calls before the compare to make the strings all the same case, but that may have other undesirable outcomes. You can always make a pull request on github because if this fixes the problem even some of the time that would be an improvement I expect, but I still wonder why more of us haven’t seen it.
An alternative would perhaps be to use the toupper() or tolower() calls before the compare to make the strings all the same case, but that may have other undesirable outcomes
yes, I’ve tried that, but strange things happened
The (most probable) reason why most people did not see the issue is perhaps the way the OS is configured or the way the application in installed/started (Loading...).
Regarding the pull request, I cannot do it, I cannot even do a git push since I have no permission to do that. Do you know who can I ask to to be granted the permission to push?
To do a pull request you fork the Fritzing app repo on Github. Then you create a branch called something like “drive_case_sensitivity” and commit the change to that branch of your fork. Then you can go to github and click the “new pull request” button while in the Fritzing repo and select your new branch and the main fritzing repo and explain why you are creating it.
My search function worked yesterday but today the magnifier is grayed out and clicking on it does nothing. I noticed severa others have the same problem. After playing around for a while by doing some of the suggestions on this forum, I noticed that there was another magnifier at the bottom of the parts bins. when I clicked on that one, the top magnifier came alive and started working. I typed Adafruit and the bin that I installed yesterday came right up. Not sure if I did anything else that may have triggered the fix but perhaps this will help someone else.