I'm a little slow here but how do I do call backs or raise events in FF3
Example PB9:
CALLBACK FUNCTION ShowDIALOG1Proc()
LOCAL wMsg AS LONG
LOCAL wParam AS LONG
LOCAL lParam AS LONG
wMsg = CBMSG
lParam = CBLPARAM
wparam = CBWPARAM
'HID messages
SELECT CASE wparam
' HID device has been plugged message...
CASE %NOTIFY_PLUGGED
OnPlugged lparam
' HID device has been unplugged
CASE %NOTIFY_UNPLUGGED
OnUnplugged lparam
' controller has changed...
CASE %NOTIFY_CHANGED
onchanged
' read event...
CASE %NOTIFY_READ
OnRead lparam
END SELECT
Routines:
SUB OnRead(BYVAL pHandle AS LONG)
' read the data (don't forget, pass the whole array)...
'IF hidRead(pHandle, BufferIn(0)) THEN
'CONTROL SET TEXT hdlg,%IDC_Recv, HEX$(BufferIn(2)) & " " & HEX$(BufferIn(1))
IF hidRead(pHandle, usbrx.pid) THEN
CONTROL SET TEXT hdlg,%IDC_Recv,HEX$(usbrx.id) & " " & HEX$(usbrx.msg) & " " & HEX$(usbrx.batt)
' first byte is the report ID, e.g. BufferIn(0)
' the other bytes are the data from the microcontrolller...
END IF
END SUB
'*****************************************************************
' a HID device has been plugged in...
'*****************************************************************
SUB OnPlugged(BYVAL pHandle AS LONG)
IF hidGetVendorID(pHandle) = %VendorID AND hidGetProductID(pHandle) = %ProductID THEN
CONTROL SET TEXT hdlg,%IDC_Status, "Connected"
END IF
END SUB
'*****************************************************************
' a HID device has been unplugged...
'*****************************************************************
SUB OnUnplugged(BYVAL pHandle AS LONG) 'this does not work for some reason
IF hidGetVendorID(pHandle) = %VendorID AND hidGetProductID(pHandle) = %ProductID THEN
CONTROL SET TEXT hdlg,%IDC_Status,"DisConnected"
END IF
END SUB
How is this done in FF3 the manual / help file says nothing I can find
thank you
Doug
You can handle all of those notifications in the "CUSTOM" message handler.
'--------------------------------------------------------------------------------
Function FORM1_CUSTOM ( _
hWndForm As Dword, _ ' handle of Form
wMsg As Long, _ ' type of message
wParam As Dword, _ ' first message parameter
lParam As Long _ ' second message parameter
) As Long
Select Case wMsg
Case %NOTIFY_PLUGGED
Case %NOTIFY_UNPLUGGED
Case %NOTIFY_CHANGED
End Select
End Function
Much easier than using that DDT silliness. :)
From the FF3 Help file:
Quote
For convenience, the most commonly used messages are displayed. However, this is not an exhaustive list of available message by no means. FireFly provides the ability to handle any message via the CUSTOM message handler. Some people prefer to handle all message, even for messages that their own separate handlers, in the CUSTOM message handler (of particular note is that the WM_CREATE message can not be handled in the CUSTOM handler). For the most part, it is suggested that you use the special separate message handlers because it makes your code more readable and modular and makes long term code maintenance easier.
Thank you Paul,
I did a search for events, callbacks, and raise events and it came back with no topics. So I guess it was in the help file after all.
I didn't think to look under custom......
I'm not criticizing but there have been a few things in the help file I couldn't find with a keyword search. I don't ask the forum until I've looked at the help. Maybe the help file can be indexed differently some how so things like callback search will point to the Custom topic. I know I hate doing documentation and it takes time away from writing code but I has to be done and in the end saves you time.
Thank you
I really like FF3
Doug
One other thing while on the subject of the help file / manual. I did a search on threading and found no topics. before I dive into threading is there anything I need to know or is it exactly like in PB9? I've used threading in PB many time with no issues. I have a feeling its a bit different in FF3.
Thanks
Doug
Doug,
FF, while it does handle some other things, is mainly the GUI handler for your program. All of the non-GUI stuff in PB is pretty much used the same way as in your old PB programs. If it uses messages, then you will have to find out where to deal with it in the form message routines in FF as you found above.
Since FF creates SDK style code, you will want to stay away from the DDT commands.
You should find that most of your code will port right over if it's not related to the GUI. You will have to put a little more work into porting the GUI stuff over, but you should get the hang of it real quick.
David
david, thank you. Yes it just takes a little getting used to. I really like FF3. There just seems to be a lot of undocumented or hard to find in the documentation features / information. As I said in my last post. Documentation is almost as hard to write well as writing the program. It usually takes another person, the software writer "assumes" the user knows xyz already or it should be obvious. I'm not saying to write at a 5 yrs old level but things like callbacks should be searchable in the documentation since it is different than in PB. I understand its a huge effort and I'm thankful for what we have.
Doug
Quote
I did a search for events, callbacks, and raise events and it came back with no topics.
Must be because with the Windows API you don't "raise events" but "send or post messages". Events are for classes.
Send or Post message returns NO TOPICS in the help file, thats my point . I know I used the wrong terminology, Raise event is a VB term. I'll be more careful. I did say callbacks also and that is the correct terminology, at least its in the PB manual. But of course you are correct Jose, I always respect your help
Thank you all it works great. Sorry I'm a bit slow at times picking things up. I work with micro controllers mostly and its a different train of thought.
Doug
Quote
I did say callbacks also and that is the correct terminology, at least its in the PB manual.
As the Pb manual deals mainly with DDT and not with the Windows API, they like to use VB terms, e.g. "A callback is a Function called by Windows when an event occurs."
For SDKer's, a callback function is a function that is called through a function pointer, that with PB you retrieve using CODEPTR(<name of the fuinction>). Contrarily to DDT, you write a callback function in the same way that any other function and can be called not only by Windows, but by other applications or your own application.
But you can also call a non callback function through a function pointer, so the only difference is that a callback function is not intended to be called by name. When you implement functions in a DLL, to be used by other applications, you export them, allowing them to be called by name. You don't export callback functions: instead, one of the exported functions will return a pointer to the callback function when required.
Thank you Jose, I need all the knowledge I can get.
Doug
To add more to the confussion, there are also callback classes, but in VB terminology they are know as event classes and in SDk terminology as event sinks.
Thank you again Jose, you're way over my head but that is a good thing. Many things would not be possible without you're fantastic work of many many include files and many other projects ( that really is not said correctly). I'm just a minor programmer writing app's to get a job done. I know just enough to get the job done and I value everyone's help. It's sad that the larger(main stream) world doesn't see what people like you, Paul and a few others have done. Maybe they have and I just don't see it. All I know is your additions to PowerBasic are extreme and enhance the language greatly. Same goes to Paul. FF3 is fantastic bridging the gap making PB better.
Thank you
Doug