SQLite seek and recordset

[travma]

Some of WinFBE demo projects compiled on Windows 7 doesn't run on XP which is bad and discouraging for programmers who try to made something only to realized that someone constantly pulls the carpet under their feet (another aspect of FUD https://en.wikipedia.org/wiki/Fear,_unc ... _and_doubt). Whats wrong with the XP based Win32 API to not be used in the first place and only offer the "new" Win32 API calls as an extension when one specifically target that new OS version or feature? Many of the demo projects doesn't even compile if I set the _WIN32_WINNT to &h0501 because the code is written to target Windows 8, so whats the point one would have to use freeBASIC as multiplatform when all older or different OS such as ReactOS thrown in garbage? API definitions does not generate security or unsupported issues. The implementations of it does it. Who in the sane mind will trust someone who "fix" the same system dll 33 times in the past but still that dll has "security issues"? Are "security issues" or the "unsupported" claim of a company is a wagon to torpedo the community or used masquerading as "new" fashion when the very same principle/politics/agenda are still in action? Rhetorical questions, no offense.

Anyway, ADO DAO has seek method to be used against an INDEX of a table. With that I can avoid to call the same SELECT SQL clause millions of times with different WHERE parameters. As a subsequence I can avoid the engine's overhead which need to parse that SQL query. Is there a way to achieve similar results using the SQLite? The database doesn't need remote access. All I want is a library function or method to seek the db in a loop (insert if not found) and once a while, outside of the loop an SQL query. Does freeBASIC/SQLite have something like the recordset of VB/Access, in order to refer and process the returned records?

[PaulSquires]

Feel free to use a different editor or write one yourself should WinFBE not be suitable for your purposes.

[jj2007]

Whats wrong with the XP based Win32 API to not be used in the first place and only offer the "new" Win32 API calls

Windows 7 support ended on January 14, 2020

[Josep Roca]

Whats wrong with the XP based Win32 API to not be used in the first place and only offer the "new" Win32 API calls

Windows 7 support ended on January 14, 2020

And Windows XP support ended on April 8, 2014.

What's wrong with XP based Win32 API? Among many other things, it has not support to write High DPI aware applications, which is very important with today's high resolution monitors.

Does freeBASIC/SQLite have something like the recordset of VB/Access, in order to refer and process the returned records?

As far as I know, no. But if you prefer ADO, then use ADO instead of SQLite.

[travma]

High DPI aware API is a non essential feature. 99.9% of the people has one monitor. Most new desktop monitors has 96-150 DPI. No manufacturer say its DPI numbers, ppi or individual pixel x/y size. If one want to support it for lets say the 4K monitor on which may drag an app from its tablet (assuming that the tablet can connect somehow to the 4K monitor, perhaps true the RDP that no one really use), then a check has to be made and then call the appropriate high DPI aware API.

Back in 1997 we have similar problem when resolution raise from 800x600 to 1024x768 or more which means that the usual screen has more space for controls. Then source code appear on VB forums that rearrange or resize the controls of a dialog or form according to current resolution or allow the end user do drag/resize the controls where he/she need to be on screen without using the bitmap bitblit M$ crap resize. Another example is that many programs like browsers has the ability to resize the web page and enlarge the letters or present bigger or smaller buttons long before High DPI aware API came out. High DPI aware API come out to offer a feature that 99.9% already existed from W95 era https://docs.microsoft.com/en-us/archive/blogs/fontblog/where-does-96-dpi-come-from-in-windows if one handles the messages and redraw the screen by his own just like browsers, VB forum code and others often do. Blurry screen may appear only when one is lazy enough and pass bitmap control to the redraw windows messages. Even then, if M$ want to deal with the problem -just from the beginning- she must decide to redraw the elements of the screen one by one and use the bitmap bitblit redraw (which produce blurry appearance only on different resolution/DPI screens) for custom controls which has no knowledge how to redraw.
Look at https://oliversturm.com/blog/2010/09/02/the-crime-that-is-windows-dpi-handling/ for the crime.

Among many other things

can stick to anything just like FUD. M$ introduce some kernel API functions, deprecate others on every "new" OS which mainly is a face lift of a desktop appearance with more eavesdropping running behind the scenes (the Fear from the FUD). The basic native kernel api, threading, Unicode, ntfs, mutex, network etc. functions are 99% the same functions with just a recompilation. 2nd prove at: https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ and at your own win32_fb.chm.

So the GUI or a code generator have to be design from the beginning to add features as they presented along the time much like browser plugins so it can evolve and not left "unsupported" like the FireFly which appears to hide somewhat the underline complexity. I guess in the question "how imagine anyone itself in the future?" the answer will be pure rage... An M$ example from system function bitblit function of the past. Internally they call pixel by pixel copy, line copy, or block copy depending on which hardware they run. Of course one can decide to allow the code to run only when the later hardware feature is present, thus byway prohibiting from certain people mindset or class functionality, benefits, knowledge, information.

If we seek to embrace every new functionality M$ propose then we must write only manage code with .NET Framework which after all runs everywhere from mobiles and linux to desktop, right?

[Josep Roca]

Windows XP on a 4K monitor is completely unusable.
See: https://external-preview.redd.it/x-UxJp ... 373e605035

Windows XP current share is a meager 1,29%
See: https://gs.statcounter.com/os-version-m ... /worldwide

If you want to support XP, it's your business. To me, it is dead and buried.

[adeyblue]

The basic native kernel api, threading, Unicode, ntfs, mutex, network etc. functions are 99% the same functions with just a recompilation

Yeah, but have you ever used NTFS transactions? Those things are sweet even if MS hate that they introduced them. Thread ordering groups and User Mode Scheduling are cool too.

Anyway, as somebody nerdy enough to have stats on this sort of thing, it's actually 97%. They removed 28 of 949 exports from kernel32 between XP SP2 and Vista SP0 and 31 of 1315 for ntdll - they added 286 and 618 respectively.
Here's a list for all dlls in System32 if you're interested in which things were removed and added. It might take a while to display because it's a 5MB XML file and uses XSL to render it into tables - http://blog.airesoft.co.uk/apichanges/X ... staSP0.xml

If we seek to embrace every new functionality M$ propose then we must write only manage code with .NET Framework which after all runs everywhere from mobiles and linux to desktop, right?

I'm confused. Is this meant to be a bad thing? Use .Net 2.0 then you can program and run it on your XP, and all subsequent versions of Windows after that will either just run it or install it for your users automatically when they run the app. Mono has its minor quirks, but your exe will very likely (99%) run on Linux and Mac without even having to recompile.
.Net seems to be the primary thing native or old-school programmers pour scorn on as something incredibly inferior but .Net is pretty whizzy.

Somebody should write an MSIL emitter for the FB compiler. Might take some of the load off of the various Pauls here who seem to be porting .Net into FB one class at a time :-)

[paul doe]

...
Does freeBASIC/SQLite have something like the recordset of VB/Access, in order to refer and process the returned records?

No, but you can always create one yourself. Here's a little snippet that'll put you on the right track:

Code: Select all

#include once "sqlite3.bi"

type _
  SQLiteRecordset _
  extends Object
  
  /'
    Rest of the code
  '/
end type

[dodicat]

FreeBASIC runs fine on Win XP.
Whether or not certain WinApi functions still work on XP can be googled for or simply tested out.
I daresay the kernell dll's change dramatically for each new version of windows.
But in the main I can run fb programs on XP, although I don't use XP much now myself (but it was a great OS), and I avoid going online with XP now.
FreeBASIC is a compiler only (Windows, Dos,Linux).
Both 32 bit and 64 bit compilers are available.
The editor is your choice, there are quite a few around.
Normally you might download the .zip file for the compiler, and the .zip file for your chosen editor.
And of course, there is nothing wrong with complaining if things don't work.

[travma]

I have a table T1 in myse3.db with two fields (wid and wordtext)

Code: Select all

CREATE TABLE "T1" (
	"wid"	INTEGER,
	"wordtext"	TEXT,
	PRIMARY KEY("wid")
) WITHOUT ROWID;
CREATE UNIQUE INDEX "wordidx" ON "T1" (
	"wordtext"	ASC
);

Is it the following code treated as prepare query because of slSelBind and slBuildBindDat ?

Code: Select all

slOpen "myse3.db", "C"
slSelBind "Select * from T1 where word = ?", slBuildBindDat("ggg", "T")
Do While slGetRow
     ? slF(1)
Loop