| View previous topic :: View next topic |
| Author |
Message |
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
 Posted: Mon Nov 29, 2004 11:57 pm Post subject: |
 |
|
Hmmm flat file database does not seem that hard. I seem to recall seeing the specifications for a flat file database with index capabilities but I don't think it had record locking so multiple users could access the database at the same time. That would be a requirement I think in todays world of DB programming. Let me finsh this version of Gadget and I think I can come up with a flat file database written as a pure VDS unit (DSU) for everyone 
_________________
Home of
Give VDS a new purpose!
 |
|
| Back to top |
|
 |
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Tue Nov 30, 2004 8:45 am Post subject: |
|
|
| jwfv wrote: | | You bring up another area of interest for me: graphics images and files. Is there a way for VDS 6 to be more "flexible" for developers of .DLLs? For instance, with a lot of third-party (non-VDS) .DLLs, they need some sort of "image container" to work with. I guess like you find in languages such as Visual Basic or Delphi. Is this out of the scope of VDS? (That type of programming is outside of my realm of knowledge.) |
I don't think I quite understand the question. You need a dialog element of some sort to display an image in. It's possible that VDS 6 will include an add-in DLL that supports display of JPGs, GIFs and possibly some other image types.
If you mean drawing graphics directly to the surface of the window or dialog, that kind of thing is achievable only at an API level, even in Delphi. I think it would be possible for an external DLL to write graphics directly to the window surface, but the application would have to be written so that the VDS code took care of redrawing the graphics whenever the window has to be repainted.
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
marty
Professional Member
Joined: 10 May 2001
Posts: 789
|
| Posted: Tue Nov 30, 2004 1:53 pm Post subject: |
|
|
Back to the database question, and I agree with you guys about having basic DB functions in VDS 6. Not specific to SQL Server, Oracle or whatever...
I will build my own SQL Server one here for VDS and my app.. I dont think it will take me long to create it..
One thing I would like to see is the possibility to have sub-menus in the taskicon menu. And why not add the possibility to add bitmaps to the menus. |
|
| Back to top |
|
|
X-Tools
Valued Contributor
Joined: 20 Sep 2001
Posts: 296
Location: Germany
|
| Posted: Thu Dec 02, 2004 8:21 am Post subject: |
|
|
Hi,
I would like to see
"select case" - Commands in VDS6
and arrays would be really great
A function to determine if an dialog element exists would be good.
After dialog create there should be a way to get the dialog number of the dialog that has recently been created. This would make it much more easier to handle multiple dialogs in one script.
The RCLICK event for table commands would be good.
And a possible bug in the table element. If I hide and table element and add data to it, it is automatically shown again. Maybe this can be solved.
XML Reading/Writing Support would be cool too
So many wishes. Sorry Hope something can be added to vds6.
Bye, Fabian |
|
| Back to top |
|
|
jwfv
Valued Contributor
Joined: 19 Mar 2002
Posts: 422
Location: Beaufort, SC
|
| Posted: Thu Dec 02, 2004 1:44 pm Post subject: |
|
|
I agree on adding an easy way to get the dialog number, without having to parse an @event(D). It would be helpful.
_________________
Joe Floyd |
|
| Back to top |
|
|
Rebel49
Contributor
Joined: 23 Aug 2002
Posts: 78
Location: Nova Scotia, Canada
|
| Posted: Thu Dec 02, 2004 11:28 pm Post subject: |
|
|
X tools wrote
| Quote: | | and arrays would be really great |
Definately would agree with that! Number 1
wish on my list. 
Also a better help file with good examples.
As VDS becomes more elaborate , it needs
that to stay POWERFUL but EASY TO USE.
and to attract more users. methinks. 
REB
_________________
OLD and eager! |
|
| Back to top |
|
|
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
| Posted: Fri Dec 03, 2004 2:53 pm Post subject: |
|
|
X-Tools,
| X-Tools wrote: | | "select case" - Commands in VDS6 |
VDS 5 already has something that does exactly what a select case does. "If elsif elsif else end" = "select case"...
| X-Tools wrote: | | and arrays would be really great |
You can use VDS lists to get the same results as arrays. I think Skit wrote some wrapper functions that does exactly this. Although I do agree that it would be nice to have native commands and functions for arrays but I would like to see the list command use a Binary or Trinary Search tree instead of it being just an array. This would speed up the list command to almost twice as fast as it is now. I use Binary search tree's inside of Gadget and it can define 800kb of definitions in memory in less than a second.
| X-Tools wrote: | | After dialog create there should be a way to get the dialog number of the dialog that has recently been created. This would make it much more easier to handle multiple dialogs in one script. |
I personally think that it would be better to instead pass the Class name or Window Handle of the dialog in the @event(D) so we can define subroutines like so. Then it would not matter when the dialog was opened and what order it was opened.
| Code: | DIALOG CREATE,My Dialog,0,0,193,95,CLASS TMyDialog
DIALOG ADD,BUTTON,Quit,36,68,64,24
Dialog Show
DIALOG CREATE,My Dialog2,-1,0,193,95,CLASS TMyDialog2
Dialog Add,BUTTON,Quit,36,68,64,24
Dialog Show
:evloop
wait event
%E = @event(D)
If %E
Goto %E
End
:QUITBUTTON|TMyDialog
:CLOSE|TMyDialog
Info See how easy this could be
Goto Evloop
:QUITBUTTON|TMyDialog2
:CLOSE|TMyDialog2
Info See how easy this could be
Goto Evloop
|
| X-Tools wrote: | | The RCLICK event for table commands would be good. |
Actually I wish they would get rid of the VDS table or replace the Table (ie.. Window's ListView control) with a real Grid control.
| X-Tools wrote: | | XML Reading/Writing Support would be cool too |
Um I think we need a open source project here at vdsworld to develop VDS 5 commands and functions to read/write XML. I already wrote a VDS function that will parse XML and give you values of elements and attributes it just needs to be developed further.
_________________
Home of
Give VDS a new purpose!
|
|
| Back to top |
|
|
ShinobiSoft
Professional Member
Joined: 06 Nov 2002
Posts: 790
Location: Knoxville, Tn
|
| Posted: Fri Dec 03, 2004 3:11 pm Post subject: |
|
|
| dragonsphere wrote: |
I personally think that it would be better to instead pass the Class name or Window Handle of the dialog in the @event(D) so we can define subroutines like so. Then it would not matter when the dialog was opened and what order it was opened |
I agree whole heartedly. There may or may not be any need for extension
developers with future versions of VDS, but as an extension developer,
this would be an easier way to return events with the appropriate dialog
number, which at this point is something I haven't figured out how to do.  
_________________
Bill Weckel
ShinobiSoft Software
"The way is known to all, but not all know it." |
|
| Back to top |
|
|
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Fri Dec 03, 2004 3:45 pm Post subject: |
|
|
| X-Tools wrote: | | The RCLICK event for table commands would be good. |
I didn't know there was an RCLICK event in VDS.
You can get right-clicks by testing in the CLICK event processing code for the table, e.g.:
| Code: | :tbContentsCLICK
if @equal(@click(B),RIGHT)
dialog popup,View file|Unzip file|Delete file
end
|
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
| Posted: Fri Dec 03, 2004 3:59 pm Post subject: |
|
|
| bweckel wrote: | There may or may not be any need for extension
developers with future versions of VDS. |
Who said there would be no need for extension developers in the future? I think there will always be a need for extensions since it would be impossible for VDS to do everything. I think that the runtime DLL does not need to get any bigger than it is. I would rather see the ability to write DLL extensions with VDS. I want to see the ability to compile a VDS 5 Unit *.dsu into a VDS DLL. Then we could write extensions in the language natively and I would not have to bang my head with C and other languages anymore. I know we can distribute the DSU's but there is no way to version stamp a *.dsu. It would also be nice to use VDS code in other languages as DLL's.
_________________
Home of
Give VDS a new purpose!
|
|
| Back to top |
|
|
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Fri Dec 03, 2004 4:39 pm Post subject: |
|
|
| bweckel wrote: | | I agree whole heartedly. There may or may not be any need for extension developers with future versions of VDS, but as an extension developer, this would be an easier way to return events with the appropriate dialog number, which at this point is something I haven't figured out how to do. |
Events pass back the dialog number because that's what you need for DIALOG SELECT. The reason you're having trouble doing this from an extension is that the externsion interface was designed with VDS 2 which I don't think even allowed child dialogs, and it certainly wasn't conceived with the aim of allowing external dialog elements tobe developed.
Because of this, the extension interface was improved in VDS 5 to support the development of external dialog elements that can be registered with VDS, which can now be addressed using the usual DIALOG commands, @dlgtext() etc. However I don't think CR ever published the details of this.
As far as I can see, if you pass a string to the event routine containing the event name (as you do now) followed by a vertical bar and a number which is the handle of the dialog containing the control that caused the event, VDS 5 will take this number and convert it to the dialog number. However, I can't verify this, as I don't actually have any examples of extensions that use this.
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Fri Dec 03, 2004 4:53 pm Post subject: |
|
|
| Quote: | | Who said there would be no need for extension developers in the future? I think there will always be a need for extensions since it would be impossible for VDS to do everything. I think that the runtime DLL does not need to get any bigger than it is. I would rather see the ability to write DLL extensions with VDS. I want to see the ability to compile a VDS 5 Unit *.dsu into a VDS DLL. Then we could write extensions in the language natively and I would not have to bang my head with C and other languages anymore. I know we can distribute the DSU's but there is no way to version stamp a *.dsu. It would also be nice to use VDS code in other languages as DLL's. |
I certainly think there should be extension developers, though the limited size of the market and the apparently poor revenue earned by extension developers is probably the main reason for putting people off.
I originally thought it would be a nice idea to be able to create VDS extension in VDS. The VDS 6 compiler will be able to build different types of executable, so one obstacle has been overcome, but you can't call the VDS 5 runtime and get a return value back, so it's never going to be possible in VDS 5.
Obviously, it's possible to change this in VDS 6, which is still at the early stages of development, but it is quite a low priority idea compared to other suggestions, as I think the application for it is really quite limited. The main advantage of writing extensions is to be able to use other languages that are able to do things you can't do easily at all in VDS (like use a lot of API stuff.) And I'm not sure there is much use for calling VDS extensions from other languages, because the interfaces exported by a VDS extension have been designed specifically to be called by the VDS runtime and are not very convenient to use by anything else. It will certainly not be possible to create a normal DLL with an interface designed by you, because that would require a linker a whole lot more sophisticated than VDS has (which is actually not a linker at all, but a program that binds resources into an executable stub.)
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
Skit3000
Admin Team
Joined: 11 May 2002
Posts: 2166
Location: The Netherlands
|
| Posted: Fri Dec 03, 2004 6:18 pm Post subject: |
|
|
I would like to see "global variables" which can be used from within multiply VDS programs. That way, you can let two programs work together, by letting the first be the "engine" and the second one the GUI, so that programs won't become unavailable while executing things. Right now I use something simulair in some of my programs, but it uses external files and/or the registry, so it isn't really fast and relyable.
_________________
[ Add autocomplete functionality to your VDS IDE windows! ]
Voor Nederlandse beginners met VDS: bekijk ook eens deze tutorial! |
|
| Back to top |
|
|
jules
Professional Member
Joined: 14 Sep 2001
Posts: 1043
Location: Cumbria, UK
|
| Posted: Fri Dec 03, 2004 7:02 pm Post subject: |
|
|
| Skit3000 wrote: | | I would like to see "global variables" which can be used from within multiply VDS programs. That way, you can let two programs work together, by letting the first be the "engine" and the second one the GUI, so that programs won't become unavailable while executing things. Right now I use something simulair in some of my programs, but it uses external files and/or the registry, so it isn't really fast and relyable. |
I don't think such a feature exists in any language. One of the early VDS extensions, written by Peter Jacob, implemented a feature like that using the registry. That's the only way I know of to intercommunicate between programs. But it depends on them running under the same user, or having access to the local machine part of the registry.
What you really need by the look of it is multi-threading, so you can run multiple processes within one application.
_________________
The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
|
vdsalchemist
Admin Team
Joined: 23 Oct 2001
Posts: 1448
Location: Florida, USA
|
| Posted: Fri Dec 03, 2004 7:16 pm Post subject: |
|
|
| jules wrote: | I certainly think there should be extension developers, though the limited size of the market and the apparently poor revenue earned by extension developers is probably the main reason for putting people off.
I originally thought it would be a nice idea to be able to create VDS extension in VDS. The VDS 6 compiler will be able to build different types of executable, so one obstacle has been overcome, but you can't call the VDS 5 runtime and get a return value back, so it's never going to be possible in VDS 5.
Obviously, it's possible to change this in VDS 6, which is still at the early stages of development, but it is quite a low priority idea compared to other suggestions, as I think the application for it is really quite limited. The main advantage of writing extensions is to be able to use other languages that are able to do things you can't do easily at all in VDS (like use a lot of API stuff.) And I'm not sure there is much use for calling VDS extensions from other languages, because the interfaces exported by a VDS extension have been designed specifically to be called by the VDS runtime and are not very convenient to use by anything else. It will certainly not be possible to create a normal DLL with an interface designed by you, because that would require a linker a whole lot more sophisticated than VDS has (which is actually not a linker at all, but a program that binds resources into an executable stub.) |
Jules,
Like all wishes they are just wishes but I am not asking for the VDS linker to be changed. I was only speaking of VDS 6. I don't expect you to go back into the VDS 5 runtime and change anything for VDS 5. Also I know it would be a huge feat to make VDS 6 build Non-VDS DLL's and still be backwards compatible. I would just like to be able to make a VDS DLL with VDS instead of using another language. At the very least I would like to see improvements in the VDS UNIT's world. I would like for them to have some kind of header information that can be read without me having to write a function to provide Version resource information. This is why I was asking for DLL abilities.
Really the biggest issue as an Extension developer and prob. why most of us have virtually stopped writting Extensions is that there is no way to protect our regcodes and no way to protect the source code in the VDS Exe.
The only thing I can do is hope that there is more honest people purchasing my DLL's than dishonest people cracking the regcodes. Well this is I think off topic but I would like more DSU and DLL possibilities in VDS 6.
_________________
Home of
Give VDS a new purpose!
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
@vdsworld