Oh boy, am I fed up!

[srvaldez]

It seems that the -O3 optimisation is a little aggressive and we have to pull back a little with some code

unless you use gcc inline asm, when using inline asm with -gen gcc it's not safe to use optimization, I suggest -O0 or at most -O1.
I could never understand the weird syntax of gcc inline asm, you can find some examples on the web but most are too simple to give an understanding of how to write more complex code.
it would be nice if we had #pragma GCC optimize ("O0")

Code: Select all

#pragma GCC push_options
#pragma GCC optimize ("O0")

your code

#pragma GCC pop_options

[deltarho[1859]]

@MrSwiss

Thanks for the German link. 1.0.7.6c is up and running. There is a lot more going on in FbEdit than I first thought. I found it a little intimidating at first but I am now starting to be the boss.<smile>

@St_W

I'm not much of a project guy but I have put a copy of your guide link into my FreeBASIC's Bookmark folder.

Btw, instead of using "fbc" in the compiler command line you can also use an absolute path to fbc.

Brilliant. I was doing a lot of testing yesterday and I was in and out of the 'FbEdit Path Options' like a yo-yo.<laugh>

@srvaldez

when using inline asm with -gen gcc it's not safe to use optimization, I suggest -O0 or at most -O1

Good advice but I cannot help 'pushing the boat out' .

Here are a couple of links for folks like me who are new to the 'hoop jumping' world of FreeBASIC.

Options That Control Optimization

When should you use the different GCC optimization flags (e.g. -O2)?

PS I am pleased to advise that I am no longer fed up. I got myself into a right old state yesterday.

[deltarho[1859]]

Btw, instead of using "fbc" in the compiler command line you can also use an absolute path to fbc.

I have 18 entries in there now including four entries of 32 or 64 Console + optimization and 32 or 64 GUI + optimization.

Very civilised.

[dodicat]

I still am unable even to get the built in -s gui to work.
And the version of fbedit from source forge doesn't even compile a .bas file.
Maybe a Win 10 thing.
Yet everything is written in fbedit.ini file.

Fbide for me as usual.

[deltarho[1859]]

Maybe a Win 10 thing.

I am on the infamous Windows 10 Creators Update which was named after the undocumented Windows API CreateGrief. I often use that but it would be remiss of me to publish the declaration.

And the version of fbedit from source forge doesn't even compile a .bas file.

That is what I was using until MrSwiss, earlier, pointed me to the German site with the latest binary.

This is so weird.

Fbide for me as usual.

That is a pity because I liked FBIde, up to a point, but FBEdit is knocking the spots off it at the moment. With St_W's guidance I can now with one click prepare a 32 bit Console compile and then with another click prepare a 64 bit GUI compile.

I wonder if anyone else has had a similar problem.

Come on folks, chip in and get this sorted out. Listen to me - I have only been here five minutes.<smile>

[St_W]

I wonder if anyone else has had a similar problem.
Come on folks, chip in and get this sorted out. Listen to me - I have only been here five minutes.<smile>

I can't understand that so many people seem to have troubles using FBedit, which is the currently best FreeBasic IDE available for Freebasic IMHO. It just works for me on any Windows version from very old ones like Windows 2000 to the most recent ones like Windows 10 without any issues. Of course I'd consider myself as advanced PC user so I often can't understand problems of beginners if they don't explain it in detail. For example beginners often even don't know what an absolute or relative path to a file is and thus have problems when setting the compiler paths / commands correctly. Unfortunately it doesn't seem to be that easy to identify the problems - they are very individual ones. Even experienced users sometimes seem to have problems using FBedit. If you could describe what is complicated in FBedit it could be fixed maybe or (more likely) tutorials/documentation focusing on those problems could be provided.

Anyway, I hope that poseidonFB gets somewhat stable at some point and can fill in as replacement for the old FBedit, which isn't maintained for quite a while.

[Josep Roca]

Personally, as I work at 192 DPI, I have problems with most, if not all, the applications that are not DPI aware: blurring fonts, artifacts, drag and drop not working correctly, etc., etc., etc.

[deltarho[1859]]

Dodicat is not a beginner. FBIde and FBEdit are both downloaded as zip files so the setting up procedure for FBEdit is the same as FBIde.

Back in Win98 days I bought a defraggler on the strength of reviews that I had read. It was a disaster. After only a few minutes it reported that it had finished. It had done very little. I tried it quite a few times with the same results. I contacted the author and he was surprised as it had been on the market for a few years and he had never heard of the behaviour that I was experiencing. Rather than spend time the author asked me to uninstall and download another copy. He did not think that would resolve the problem but it was course of action which should be eliminated. The second download worked perfectly. I advised the author and suggested he put a MD5 checksum next to his downloads. He said he would and when I checked his site a few days later all his downloads had a MD5 checksum.

The interesting thing about this story is that I had a corrupted binary, either via downloading or unzipping, but the corruption was invisible. it loaded, the GUI was OK - in fact all appeared well. The only thing that the corruption did was to stop the application performing as intended.

So, I would suggest that dodicat goes to the German site and get a copy of the latest version: FBEdit 1.0.7.6c

In the meantime I shall keep my fingers crossed, but not for too long - it is very awkward drinking a cup of tea with one's fingers crossed<smile>

[dodicat]

Yea, I got that one a while back deltarho[].
I transfered the folder directly to the c drive.
So I have C:/FbEdit.

The compiler swithes ( -s gui .. etc) only work with the fully compiled file, not with the quick run.
So
Make -- compile (the switches are observed only here!)
Make --- run.

With switch -s gui (Windows Console), the Make run is left poised on the taskbar, OK, not really a problem, just a nuisance.
Still the problem of having say 5 files up on the ide, and you are coding the far right one.
You make a little typo and quick run.
The ide flips back to the first on the left.
not really a problem just a nuisance.
I think my fbetdt installation is a little bit buggy.
It is 1.07.6c

[deltarho[1859]]

@dodicat

I am a little confused. I got the impression that your copy of FBEdit pretty much wasn't doing anything right which is why I suggested a fresh download.

Anyway, when a Help file is written by the author of the code they very often fall well short of what a user needs. Writing a good Help file requires that the code's author removes their coding cap and dons their user's cap. Unfortunately, many a code's author are unable to do this. We all know that writing code requires tenacity. Well, so does writing a Help file. Unfortunately, many a code's author do not employ the same tenacity when writing a Help file as they do when coding.

FBEdit's Help falls well short of being half decent: It has no Index to speak of and no Search facility.

In the Make menu we have 'Go' and 'Quick Run' and neither of them are to be found in Help. To be sure I loaded the chm into TextPad in binary mode and searched.

As you pointed out the 'Quick Run' does not observe switches. I compiled some code using my '32 bit Console + opt' build and then executed 'Run'. I then executed 'Quick Run' and it was clear that the opt switches were not being observed. Now, it could not have been using the previous binary, otherwise the switches would have been observed, so 'Quick Run' must be a compile and run command.

Oh dear, this is where a good Help comes in. In 'Options>Debug / Quick run Option' we can actually define what 'Quick Run' does.

It is quite easy to have our custom build and 'Quick Run' out of sync with regard the executable subsystem.

I think I remember someone using the term 'jumping through hoops'. Oh, that's right - it was me.<laugh>

[deltarho[1859]]

Come to think of it, St_W may like to consider mentioning the 'Quick Run' build in the 'How to change compiler command line in FBedit' pdf.<smile>