Wow I just found FF earlier today and must say it was something of LAFS and it sure looks very promising. But as many others I'm a bit puzzled about this Win32.API SKD stuff although I have a fair understanding of what it is - just haven't used it before in this "hands on" way. Coming from VB6 (where I still have my main code base) I resently picked up PBWIN8 & PBFORMS as M$ "abandoned" the ship to slowly sink... and my plan is to step by step "transfer" my code over to use the PBWIN8 compiler. Without doubt it superiour VB6 in many ways (and many times) except for the code editor/designer so guess if I'm happy to have found FF (like that name btw) and most likely will register within short (running the evaluation now).
Ok enough ranting and over to my "problem". I do understand the use of the FF_functions pretty well, but there is one thing that puzzles me. In moving my code over from VB to PB I have choosen an approach of "cutting out" pieces to make ddl's which I then can use in my working VB apps. Just before I found FF I was just able to complete one such DLL using the native PB editor. My aim is now to move that code into FF so I start a new DLL project which gives me a FF_LibMain tab. I understand that is supposed to replace the LibMain function I have in mydll.bas file... but then? Here is where I become a bit confused, were do I place other "basic" thinks like metastatements, Types,equtes, declarations and globals etc.? The main part as functions and subs is probably best dealt with by adding as a module but will I better keep the other things there as well or does it even matter?
I couldn't really find anything about this in the help file, although I might have missed it. I understand I somewhat comes in the "wrong" way as the main focus of FF is on the visual design part and I will sure come to that as well, in due time. I have picked up JellyFish as well and it maybe would be an easier route to go, but I really like the idea to have everything in one place (and is kinda used to it from VB) so that's not really what I want to do. My main focus now just happens to be on the DLL side.
So if i just can get passed this stupid little obstacle I'm sure we will have a lot of fun in the future, me and FF :-)
Thanks in advance,
Joakim
Hi JoakimS, great to have you here. I also came from an extensive VB background (although I switched away from VB 3 or 4 years ago). If you have questions, make sure that you post them here or over in the PB forum. There are lots and lots of people that use PowerBASIC who came from a VB background and will be quick to help.
Quote from: JoakimSMy aim is now to move that code into FF so I start a new DLL project which gives me a FF_LibMain tab. I understand that is supposed to replace the LibMain function I have in mydll.bas file... but then? Here is where I become a bit confused, were do I place other "basic" thinks like metastatements, Types,equtes, declarations and globals etc.? The main part as functions and subs is probably best dealt with by adding as a module but will I better keep the other things there as well or does it even matter?
It doesn't really matter. Actually, it is a matter of taste. You can simply add your types, equates, declarations, globals at the beginning of the FF_LIBMAIN function, or you can add one or more 'modules' to the project. FireFly will gather all of your files into a compiled version. Organize your project for clarity. If that means adding 20 modules, then that's what you should do.
Also, FireFly automatically handles adding the function/sub declarations so you do not need to do that in your program listing.
QuoteI have picked up JellyFish as well and it maybe would be an easier route to go, but I really like the idea to have everything in one place (and is kinda used to it from VB) so that's not really what I want to do. My main focus now just happens to be on the DLL side.
Yes, that is a matter of preference as well. I use FireFly sometimes for creating DLL's (when I want a Form to be the DLL), and sometimes I use JellyFish to create the DLL. Just a matter of taste.
Thanks for fast reply, I'm aware of the PB forum and havent had to ask anything ther eyet due to it have a search function :-)
Anyhow, I tried to compile my project in FF (which compiles fine in JF) but get a syntax error 477 in FF and this line
Declare FUNCTION FileToArr(BYVAL sFilePath AS STRING, BYREF sArr() AS STRING) PRIVATE AS LONG
the Declare part must been put there by FF as it's not in my code BUT I sure cant see anything wrong with the rest? the whole function looks like thisFUNCTION FileToArr(BYVAL sFilePath AS STRING, BYREF sArr() AS STRING) PRIVATE AS LONG
LOCAL fHandle AS INTEGER
LOCAL count, num AS LONG
' ensure that the file exists
IF cFilePathExists(sFilePath) THEN
fHandle = FREEFILE
OPEN sFilePath FOR INPUT AS fHandle
FILESCAN #fHandle, RECORDS TO count&
DIM sArr(0 TO count& - 1)
' read the string and close the file
LINE INPUT #fHandle, sArr() RECORDS count TO num
CLOSE #fHandle
END IF
FUNCTION = num
END FUNCTION
I can't see anything wrong with this either so I'm puzzled as the sole bas file I "imported" compiles in JF! The only thing I have done is to move my code in LibMain into FF_LibMain, which indeed use this function in a sub call. From FF_LibMain Case %DLL_PROCESS_ATTACH
'Indicates that the DLL is being loaded by another process (a DLL
'or EXE is loading the DLL). DLLs can use this opportunity to
'initialize any instance or global data, such as arrays.
FileVersion = 5.7!
Local InstallDir As String
InstallDir = FF_GetRegistryString(%HKEY_LOCAL_MACHINE, $REGBAS, "InstallPath", "")
If Len(InstallDir) <> 0 Then
If Right$(InstallDir, 1) <> "\" Then InstallDir = InstallDir + "\"
CommonDir = InstallDir & "Common\"
Call LoadChartTxtMess
Function = 1 'success!
Else
Function = 0 'failure! This will prevent the DLL from running.
End If
and then LoadChartTxtMess SUB LoadChartTxtMess() PRIVATE
LOCAL fi AS STRING
LOCAL i AS LONG
DIM ChartTxt() AS GLOBAL STRING
fi = CommonDir + "chartdata.arr"
IF cFilePathExists(fi) THEN
i = FileToarr(fi, ChartTxt())
REDIM PRESERVE charttxt(i)
END IF
END SUB
There must be something here that upsets FF and makes it inject something erronic to PB8, at least it the only thing I can come to think of, just can't figure out what?
TIA
/Joakim
Hi,
Try removing that PRIVATE keyword from your Function heading and then re-compile in FireFly.
I am not at the FireFly source code, but it could be that the PRIVATE keyword is causing a problem.
Quote from: TechSupportHi,
Try removing that PRIVATE keyword from your Function heading and then re-compile in FireFly.
I am not at the FireFly source code, but it could be that the PRIVATE keyword is causing a problem.
Ice cream & honey pie - that's it! I removed Private and the error jumped on to next Private procedure.
Thanks a lot for great support! I will definately register within short.
/Joakim
EDIT: I just have to get over that I bucked out $99 for PBFORMS, which I haven't even used yet, for no reason it seems.
Yes it compiled! :D but the dll came out at a size of 135k, when compiling it in JF it's just 96k, I can get it down to 103k by unchecking XP Themes support and check Dymanically create CommCtrl.inc exclude equates. Still 7k missing though :twisted:
Yes I can live with that but I try to learn and understand the tool and just wonder were these 7k comes from - is it FF_functions overhead or?
I know there is an exelent tool by Börje, incLean and have put the dll in FF's dir - but can't find anything on what to fill in the Add Tool dialog with?
Also by search I came across something about checking "Use incLean" in environment settings but I can't see any such option there - has it been removed or is it an "undocumented" limitation of the Eval?
Couldn't find anything on this in neither of the PB forums or Börjes site or I wouldn't ask :roll:
Sorry to be such a pain :twisted: but in making further investigations in this totally meaningless dram "in search of the hol... I mean lost 7k", I run the produced JF project file to compile in JF but get an "Compiler Log Error, Compiler log file not found. Attempted to read the file: CODEGEN_CHARTDATA_MAIN.log Current directory C:\ "
You might be aware of it but thought I point it out anyway. The last part really puzzles me as I loaded by Dclick the project file and it's located on my D: drive were I have all my source code. I didn't thought it was a JF issue as FF is creating the project file, but maybe it is as there is nothing about .log in the jfp file.
Ok now I will try to be a bit productive as well :wink:
I had to remove support for IncLean from FireFly. Too bad really because I used it on all my personal projects. The reason it was removed is because the new include files for PB/WIN 8 and PB/CC 4 are not compatible with Borje's utility (and Borje is not updating the utility to handle them).
Too bad really. :(
Quote from: JoakimSSorry to be such a pain :twisted: but in making further investigations in this totally meaningless dram "in search of the hol... I mean lost 7k", I run the produced JF project file to compile in JF but get an "Compiler Log Error, Compiler log file not found. Attempted to read the file: CODEGEN_CHARTDATA_MAIN.log Current directory C:\ "
You might be aware of it but thought I point it out anyway. The last part really puzzles me as I loaded by Dclick the project file and it's located on my D: drive were I have all my source code. I didn't thought it was a JF issue as FF is creating the project file, but maybe it is as there is nothing about .log in the jfp file.
Ok now I will try to be a bit productive as well :wink:
I have seen that error a few times as well when running the FireFly produced JellyFish project file. I am not quite sure what is causing it (granted, I haven't done much investigation into it either).
Try just loading the main .BAS created FireFly file instead of the project.
Quote from: TechSupportI had to remove support for IncLean from FireFly. Too bad really because I used it on all my personal projects. The reason it was removed is because the new include files for PB/WIN 8 and PB/CC 4 are not compatible with Borje's utility (and Borje is not updating the utility to handle them).
Too bad really. :(
Maybe just need some pushing, I mean this must be a problem for the whole PB comunity using incLean, is Borje aware of the problem?
It would have been nice to see what it comes down to with a cleaned up .inc file set. As an example, one thing noted is that FF insisted to put in
#Include "COMDLG32.INC"which is total bloat as the dll doesn't have any form or such, now I don't know how much that will do or if it can be avoided?
One think that stroke my mind though was the options I could check/uncheck in Environment option, why do they have to be "Global"? To me it looks like they are more project based settings, so why not in the Project Options? No you have to remember and change switching between different project, instead of "set and forget"... well just a reflection.
/Joakim
May I sneak in another little "wish" as well, the option to have the Project name different to the compiled components name. Especially for dll's you may like to have a somewhat "cryptic" name on the compiled dll to not colide with others but it's nice to have a "descriptive" project name.
Ok that's it for today.
/Joakim
Borje is aware of it. He let me see the source code sometime back so I could attempt to rewrite something for FF. Too many other things have came up and it is somewhat on hold. I plan on it being like a FF addon. Paul just needs to add support for one more switch and it will be easy to integrate it.
Borje's code is nice, but it wasn't that helpful. It pretty much did what I imagined, but in a very complex way. I'm surprised it didn't run into any other issues with everyone's different styles of programming. The big hurdles are Macros and Dynamic reading of all the files so it can keep the structure of the compiler directives. One nice thing is that equates and types don't matter since they are only compiled when used. So it is just a matter of loading every file inline and keeping the Sub/Function blocks and compiler directive blocks around them of Functions/Subs that are used.
It sounds easier than it is though. It would almost be easier to give the code to Paul when I'm done to put it in with what FF already does for optimizing.