strcat string / string unicode

[Secondlaw]

I think I'm having an issue I'm using strcat to create a section heading for a .ini file via askitemlist.

What I'm essentially doing is putting something together to read sections of a .ini file based on some answers.  The result is this:

[My_Inifile_PROD]

This works with no issue e but I can't seem to read any of the values of the inifile located under that section heading.  I  run through debug mode and I presume the answer is because it's turning up as, "string_Unicode" rather than a regular string.

Can I convert this to string so I can read the section out of my .ini file?

Thanks!

[td]

WinBatch initialization file functions do not return values as Unicode.  Specifically, the IniReadPvt only returns ANSI strings so your understanding of the contents of the WinBatch Studio "Watch" window must be off a bit.   

Also, all of the initialization file functions will convert any Unicode parameters passed to the functions to ANSI before any data is written to a file.   

[Secondlaw]

I think you misunderstood something (maybe I didn't explain it correctly)...  IniReadPvt is not a concern.

AskItemList is returning String_Unicode.  If you need a screenshot of the debug window, I can provide that.

[td]

You never mentioned anything about the AskItemList function in your original post but it does not matter.  As previously mentioned WIL functions including IniReadPvt and AskItemList do not care if the input for one function passed to the next function is Unicode or ANSI. In almost all cases it makes no difference.

To put it another way, without a more detailed description of what you are doing it is difficult to tell what your issue is but it is most likely has nothing to do with Unicode.

[Secondlaw]

Okay...  So essentially what I'm doing is creating a .exe that does this.

1.  Asks for a name.  (AskItemList)
2.  Asks for another name.  (AskItemList)

The names are from a list that I'm pulling from a .INI file.

Let's take these two names for example.  Step one we'll select "SECOND" from a provided list of names and Step two we'll select "LAW" from another provided list of names.  So we now have two variables.  We'll call variable 1, "Firstname" and variable 2, "Lastname". 

What I'm doing with these names is putting them together for reading out of a .INI file section heading.

[SECOND_LAW]
value1=24
value2=Testing
value3=Home

Now I'd like to read out of the .ini, the values under the "SECOND_LAW" section heading and use those variable in various places throughout my script.

The issue for some reason is that I cannot inireadpvt any of the values from the section heading, "SECOND_LAW".  The common thing with any of these particular variables in the debug mode is, "String_Unicode" while the other defined variables are simply strings. 


I'm sorry if I'm not explaining this clearly. 

[stanl]

Although IMHT it would make more sense to use a database: you seem to imply

Code (WINBSATCH) Select Expand


cINI = [your ini file]
step1="SECOND"
step2="LAW"
inihdr=step1 : "_" : step1
retval = IniReadPvt("value1","%inihdr%","",cINI)


and retval returns a Unicode string.

[td]

The issue for some reason is that I cannot inireadpvt any of the values from the section heading, "SECOND_LAW".  The common thing with any of these particular variables in the debug mode is, "String_Unicode" while the other defined variables are simply strings. 

Based on your description, Unicode doesn't matter and is not the cause of your problem.  You are performing what could be called "gestalt debugging".  That is, you noticed a difference and decided that that must be the cause because you noticed it.

[Secondlaw]

Here is the code I'm having an issue with:

Code Select Expand

ErrorMode (@OFF)

RunFrom=DirScript()
INIFILE=StrCat(RunFrom, "Deployme.ini")

LocalServer=IniReadPvt("COMMON", "LocalServer", "", INIFILE)
APPNAME=IniReadPvt("COMMON", "APPNAME", "", INIFILE)
DEPLOYTIME=IniReadPvt("COMMON", "DEPLOYTIME", "", INIFILE)
PACKAGETYPE = IniReadPvt("COMMON", "PACKAGETYPE", "", INIFILE)
LOGFILEPATH=IniReadPvt("COMMON", "LOGFILEPATH", "", INIFILE)

cmd =  Environment('COMSPEC')
windir = Environment('Windir')

CurrentTime=TimeYmdHms()

Selected=AskItemList("Choose Package Type", PACKAGETYPE, ",", @SORTED, @SINGLE, @FALSE)
APPNAME=AskItemList("Application Name", APPNAME, ",", @SORTED, @SINGLE, @FALSE)

HEADING=strcat(APPNAME, "_", Selected)
HEADING=strcat("[", HEADING, "]")
MSGTXT=strcat("Ensure this section heading ", HEADING, " is in the Deployme.ini file prior to continuing")

HEADING=(Heading)
;MESSAGE("WARNING!", MSGTXT)

PackagePath=IniReadPvt(HEADING,"PACKAGEPATH","",INIFILE)
Serverlist=IniReadPvt(HEADING,"SERVERLIST","",INIFILE)
CommonPackagePath=StrCat(LocalServer, "\", PackagePath)
CommonPackagePathFiles=strcat(CommonPackagePath, "\", "*.*")

[td]

For the fourth time, your problem has nothing to do with Unicode.  You are placing square brackets around the section name before passing the section name as the first parameter to  IniReadPvt.  Not only is that not necessary but it will cause IniReadPvt to fail to find your section name.  Look at the example in the Consolidated WIL Help file and note the section name.

You should also get rid of the ErrorMode call while debugging any script.

[Secondlaw]

This is obviously user error on my part.  I overlooked something.  All I was looking for was this:

"You are placing square brackets around the section name before passing the section name".

I have hundreds of these scripts that I created and they all work great.  I couldn't figure out why my section headings weren't reading the values. 

Thanks for the input.  That of course solved the issue I was having.

[kdmoyers]

<< You should also get rid of the ErrorMode call while debugging any script. >>

Goodness YES, double Yes.   It's effect is to shift the apparent location of errors, not remove any error.  Once you get that, you almost entirely stop using it.

[td]

It is curious that the image attachment of the WinBatch Studio Watch window with Unicode variables highlighted has disappeared from the OP's next to the last post.  Either an act of history revisioning was performed or the forum software has an issue.  The latter of which is a concern.

[stanl]

Off Topic: haven't upgraded yet but curious as to whether the new WB 'mapping' would work faster than an .INI

[td]

Interesting thought and to be honest I don't know.  A hash table is usually faster than a linear search of the same data but Windows ini files get special treatment by the OS.  It could be that Windows hashes ini files when it loads them or something.  I guess the only way to find out would be to run a test.

[Secondlaw]

I removed the attachment but I can re-up it if need be.  The code I used is still available.

[td]

This forum, as well as many other forums, have been the target of an ongoing SQL injection attack.  The forum uses several safeguards that block such attacks.  However, the web server software has to do some processing before it knowns to block it.  Because of their frequency, the attacks can almost become a DOS attack.   In order to reduce the load on the server, we experimented with several server configuration changes that theoretically could catch packets much earlier in the process and greatly reduce the load on the server.   We found a combination that appears to work but we are still concerned about the potential for unintended consequences of the changes. 

So any time something the least bit unexpected happens on this forum it gets noticed.  But now that the cause is known this event can safely be ignored.