jaPBe 3.13.4 [IDE for PB 4 and PB 5]

[gnozal]

Gnozal, just loaded jaPBe v3 for the first time and opened the prferences page and something strange happened.
Somehow, I don't think this was supposed to happen:):)

Somehow, I think you are right

Did you have two gadgets on top of each other accidentally?

Yes, and nobody ever noticed it !

Should be fixed in new build (download updated).

[Fangbeast]

ROFL!!! It's rare for me to find bugs in anything as I am the least able programmer:):)

[chen]

Did you check APPDATA ?
(Open console, type 'SET' + Return, look at APPDATA value)

APPDATA = C:\Documents and Settings\Administrator\Application Data

and here is "PureBasic" directory and inside it:

PureBasic.prefs
Templates.prefs
Tools.prefs


PureBasic.prefs has information... but anyway jaPBe continues sending me
the message:

"PB IDE preference file not found! Please start Purebasic.exe at least
one time."

[gnozal]

Did you check APPDATA ?
(Open console, type 'SET' + Return, look at APPDATA value)

APPDATA = C:\Documents and Settings\Administrator\Application Data

and here is "PureBasic" directory and inside it:

PureBasic.prefs
Templates.prefs
Tools.prefs

Here is the code

Code: Select all

If FileSize(PBPreferencesPath$ + "PureBasic.prefs") < 1
  If FileSize(PureBasicPath$ + "PureBasic.exe") > 0
    pref_WriteColorPrefsToPBIDE()
  Else
    PopUpMessage(Language$(493)) ; ---> the message ...
  EndIf
EndIf

Where PBPreferencesPath$ is :

Code: Select all

    If PBVersion$ > "4.02"
      PBPreferencesPath$ = SpecialFolder(#CSIDL_APPDATA) + "\Purebasic"
    Else
      PBPreferencesPath$ = PureBasicPath$
    EndIf

So if PureBasic.prefs exists in APPDATA, does the file 'PureBasic.exe' exist in PureBasicPath$ (defined in jaPBe preferences) ?

[inc.]

Hi Gnozal,

maybe I missed that thing but ...
would it be possible that jaPBe provides environmentvariables during Compile-Time like done by IDE?

JAPBE_TOOL_IDE - Full path and filename of jaPBe
JAPBE_TOOL_Compiler - Full path and filename of the PB Compiler
JAPBE_TOOL_Language - Language currently used in jaPBe
JAPBE_TOOL_FileList - A list of all open files in jaPBe, separated by Chr(10)

JAPBE_TOOL_Debugger - These variables provide the settings from the Compiler Options
JAPBE_TOOL_InlineASM window for the current source. They are set to "1" if the option
JAPBE_TOOL_Unicode is enabled, and "0" if not.
JAPBE_TOOL_Thread
JAPBE_TOOL_XPSkin
JAPBE_TOOL_OnError

JAPBE_TOOL_SubSystem - content of the "Subsystem" field in the compiler options
JAPBE_TOOL_Executable - same as the %COMPILEFILE token for the commandline
JAPBE_TOOL_Cursor - same as the %CURSOR token for the commandline
JAPBE_TOOL_Selection - same as the %SELECTION token for the commandline
JAPBE_TOOL_Word - same as the %WORD token for the commandline

JAPBE_TOOL_MainWindow - OS handle to the main jaPBe window
JAPBE_TOOL_Scintilla - OS handle to the Scintilla editing component of the current source in jaPBe

I know there's a pluginframework jPBe does come with but a support of these env.variables above would make the development of Cross-Coding-Environment PlugIns much more easier.


Another point I did figure out is that in the IDE when providing the argument "%TEMPFILE" and configuring the tool to overwrite the existing source, actually the source in the window is overwritten but NOT safed which should be the sense in case of a just text modifying plugin.

But in jaPBe I have to set "%FILE" as argument for supportig the overwriting of the current source in the editing window. Now ... this also forces the source to safed automatically which imho is VERY risky As jaPBe by this will affect the orig source where the IDE only affects a pre-build tempfile.

Many thanks in advance and as always: thanks for all your efforts on PB!
Inc.

[gnozal]

would it be possible that jaPBe provides environmentvariables during Compile-Time like done by IDE?

It's possible : here you have a beta to play with : http://freenet-homepage.de/gnozal/jaPBe_BETA.zip
Of course, it won't work well with Win98 (too much environment used).

[EDIT] Download updated JAN 10th 09:00 GMT+1

[inc.]

Merci beaucoup!

Ill check it out this evening!

Best greets.
Andrej

[freak]

Why name them "JAPBE_TOOL_ ..." and not "PB_TOOL_ ..." like in the IDE ?

Since you are just copying the IDE behavior, why not keep it compatible so people
can write tools for both editors ?

[inc.]

Freak, ... what happens if both IDEs are open?
Does the specific EnvVariable will be provided only during the compiling runtime?

If yes it shurely would make sense just to keep the same EnvVar names as used in the IDE as Freak pointed out.

Beside this, there are still differencies as mentioned regarding %TEMPFILE in the IDE and %FILE in jaPBe and their reload source behaviour.

[freak]

Environment variable changes only affect the current process and any child processes
it creates after the change. So there cannot be conflicts like that.

[inc.]

would it be possible that jaPBe provides environmentvariables during Compile-Time like done by IDE?

It's possible : here you have a beta to play with : http://freenet-homepage.de/gnozal/jaPBe_BETA.zip
Of course, it won't work well with Win98 (too much environment used).

[EDIT] Download updated JAN 10th 09:00 GMT+1

It works, many thanks!
I revert my suggestion and do agree with Freak and also think we should keep the EnVars names as provided by the IDE.

[gnozal]

Update

Changes :
- new option in Preferences [Editor 2] : 'Create PB_TOOL environment' (if checked, jaPBe provides additional information for the tools in the form of (PB IDE compatible) environment variables).
- manual (separate download) updated.

[inc.]

Why aren't the EnvVariables provided per default? Please.
Altering the preferences will be another step you will have to point the user to when offering a plugin. The sense is, just use a cross-environment-tool the same way as in the IDE like in jaPBe. Just setup the tools config, thats it.

If you want to make it switchable, then I do think it would be less complicated for the user if you would place that switch into the tools config.

[gnozal]

Why aren't the EnvVariables provided per default?
It's another step you will have to point the user to when offering a plugin.

Because I didn't test it on Win9x, where iirc environment space is very limited, and imho 99% of the users wouldn't use it anyway.
If it works without problems, I could enable it by default in the next version.

[freak]

The MS-SDK makes no mention of any limits concerning older Windows versions
and the environment variable commands. I don't think there will be a problem.