Hi, and thanks for the advice. This is the VB6 code:
.DrawMode = vbInvert 'or vbXorPen will work
frmEntryscreen.Picture3.Line (0, 0)-(.ScaleWidth, .ScaleHeight), vbWhite, BF
frmEntryscreen.Picture3.DrawMode = vbMaskPen
frmEntryscreen.Picture3.Line (0, 0)-(.ScaleWidth, .ScaleHeight), vbRed, BF
(picture3 is, of course, the chart which is 'black stars on a white BG'). I didn't post this question under 'earlier' VB since that's not what the problem is - didn't want to complicate matters! I also tried the MS site as suggested by someone else but everything there only seemed to apply to recolouring the entire image as a whole, which isn't what I need to do. I envisage the task as being in 2 stages (but as I'm not a buzzing vb.net person don't know if this is what's required) - stage 1: Make a negative image, so white stars on black BG. Stage 2:change all white pixels to red ones.
There is no transpile to C++ code. The JITter converts IL code to native directly.
As to why .NET compiles to IL; the core of .NET is a machine agnostic framework so, while historically, the most common implementation was for PCs, there was no absolute requirement that it be constrained to PC. By using IL, you can port that onto a number of different platforms and have it JIT to IL for that platform. This is a common paradigm, favoured by languages such as Java.
Let's work this through logically. You're looking for a version of a tool that's available on this site so you could have asked on the forum for that article, instead you left it for others to search to find out what tool it was. Having found the right tool, I had a quick look at the revision history; given that the last update was May 2017 and 4.7.1 was the release for the W10 Fall Creators Update, and the SDK has a date in October 2017, I would have to say that it isn't a 4.7.1 update.
I have a payment form, in this form, I have a datagridview which listed all the invoices of a certain customer. when I press okay to pay, all of the listed invoices should be updated with close. Here is the code i used and its not working.
Private Sub updateinvoicepaymentstat()
conn.ConnectionString = "Server = '" & Servername & "'; " _
& "Database = '" & DBName & "'; " _
& "user id = '" & sqlUName & "'; " _
& "password = '" & sqlPwd & "'"
For x As Integer = 0 To dgvinvoicedetails.Rows.Count - 1
Dim sqlcommand As String = "UPDATE purchaseinvoice SET partialpay=@bal where docentry ='" & dgvinvoicedetails.Rows(x).Cells(0).Value & "'"
Dim command As New SqlCommand(sqlcommand, conn)
You are not checking the return value from ExecuteNonQuery to see whether the call succeeded, so you have no idea what is happening in your code. Add proper error checking, and log, or display information if the call fails. You can also use the debugger to check the actual values of any variables used by the UPDATE statement.
On top of what Richard said, you're using a SqlParameter object for one parameter but not the other? Why? ALWAYS use parameter objects for every parameter! NEVER use string concatenation to build an SQL query.
System.ItDidntWorkException: Something didn't work as expected.
-- said no compiler, ever.
(I am sorry if this is an old question - the search mechanism doesn't work today: If I click a hit list entry, it doesn't show that message, but goes to the top of the forum; I don't get to read the question/answer.)
I started out in Win7 using constants for identifying extended file system attributes (such as "Link target"). Then came Win8, and I learned the truth of "Constants ain't; variables won't": I had to check the OS version and select the attribute number from one of several tables. Win10 came with yet another set of "constants" to select the attributes - yet another table.
Then came a Win10 update that changed the constants again - but still the OS identifies itself as Win10. Rather than adding another table for (potentially) each OS update (they were compiled into the code, so a new revision meant I had to distribute a new version of my code), I changed the strategy to dynamically build a table of attribute names, their index in the array being the attribute number. (You get the attribute name by calling GetDetailsOf with 0 as the first argument.) This has worked for some time.
Then comes this guy from our development group in Poland, complaining that my code doesn't work. After an extensive search, it turns out that it fails when he is running the code on a machine with a Polish Windows version: GetDetailsOf(0, AttrNo) returns the Polish attribute name. When my code looks for, say, "Link target" in the table, it won't find it.
I could make those guys provide a list of the Polish names, so that I search for either "Link target" or whatever Link target is in Poland. I will have to compile a new version, then the Polish guys will be happy. Maybe our Finish office will come three months later and tell that they have switched to Finish Windows versions (currently they use an English/US version), and I have to make a new version looking for either the English, the Polish or the Finish attribute name.
Is there no way to identify a given extended attribute in a general way, independent of language version, independent of OS version? A way that works in Polish Windows even of I don't know the Polish attribute names, in Finish Windows even if I don't know the Finish names, or in any other languge where I don't know the terms?
I am NOT going to translate the entire UI to umpteen languages - I am making programmer's tools, and a programmer can use an English language UI. What I need is to get the information from the file system in a language independent way!
If you ask for the name of an item then you will get it in the local language. You could try setting the default culture to English in order to get the name you expect. But a better idea is not to try and get names and compare them to strings, but to check the type of the item as described at FolderItem object (Windows)[^].
However, I may have misunderstood your question as it is not exactly clear what you are trying to achieve.
- as you can see, I both set DetfaultThreadCurrentCulture and CurrentThread.CurrentCulture. The table is still filled with English attribute names, rather than French. I sort of doubt that any Windows installation can take on any culture from any place in the world - it may be possible to install it, but it is not necessarily install it.
My immediate need right now is when I have detected that a file is a symlink / junction, to know programmatically what the link refers to. If in Windows Explorer display the Properties of the file, it comes up as "Target:" in the "Shortcut" tab. In my current Win10 version, I can obtain the target path by
- I find "Link target" in element 196 of the above table. In other Windows versions, the index is different, so I initialize the table at startup and search for the string "Link target" when I need to look up that attribute number.
I have not found any alternative way to get hold of the link target. (I could use a command shell, giving a dir command and parse the output - but what are the commands, and what shoult I look for, in a Polish language command shell?)
Later, I will make use of more of the attributes not available through the basic attributes, such as the media description attributes (e.g. Duration, Frame width, Frame rate, ...) or author info. If there is another (language/version independent) way of obtaining the target of a symbolic link, I would be helped in the short term, but in the long term, I would need programmatic access to a whole lot of these attributes, preferably all those that can be displayed as an Explorer column.
This information is saved in the file system. I would be extremely surprised if each attribute value is tagged with a language specific attribute name. I would also be surprised if they are tagged with the index I see and use through GetDetailsOf - then, any Windows update would require a re-tagging of every file on every disk, and I couldn't take that disk over to an older version OS without loosing the attributes. Which identification mechanism is used in the NTFS metadata to recognize, say, the link target, or the video frame rate? Is there any way I can ask by the same ID that is used internally within the NTFS file system?
It seems as if DeviceIoControl has not yet been wrapped up for C# access. While I certainly could spend the resources doing that, it certainly will be very much a short-term solution, solving only one of my needs. As I wrote in my previous post, I will need acess to a bunch of these attributes, and the other ones are not available through DeviceIoControl. The effort spent for solving a fraction of the problem is wasted when I find a more complete solution.
If I ask those Polish guys what "Link target" is in Polish, I can solve my immediate problem with a small fraction of the effort of learning the intricasies of DeviceIoControl and making a C# interface to it. (I did program IOCTL in the old DOS days, and I am convinced that this modern variant is no less complex when I start digging into it.)
Have you ever practiced coding online to prepare a technical interview or to groom your skills? If yes, how well it was? Which websites have you used? And, how effective they were? If possible, share the challenges you have faced?